i386-cygwin-tdep.c has just been renamed to i386-windows-tdep.c, this
patch now renames everything in it that is not Cygwin-specific to
replace "cygwin" with "windows".
Note that I did not rename i386_cygwin_core_osabi_sniffer, since that
appears to be Cygwin-specific.
gdb/ChangeLog:
* i386-windows-tdep.c: Mass-rename "cygwin" to "windows", except
i386_cygwin_core_osabi_sniffer.
Since this file contains things that apply not only to Cygwin binaries,
but also to non-Cygwin Windows binaries, I think it would make more
sense for it to be called i386-windows-tdep.c. It is analogous to
amd64-windows-tdep.c, which we already have.
gdb/ChangeLog:
* i386-cygwin-tdep.c: Rename to...
* i386-windows-tdep.c: ... this.
* Makefile.in (ALL_TARGET_OBS): Rename i386-cygwin-tdep.c to
i386-windows-tdep.c.
* configure.tgt: Likewise.
GDB currently uses the "Cygwin" OS ABI (GDB_OSABI_CYGWIN) for everything
related to Windows. If you build a GDB for a MinGW or Cygwin target, it
will have "Cygwin" as the default OS ABI in both cases (see
configure.tgt). If you load either a MinGW or Cygwin binary, the
"Cygwin" OS ABI will be selected in both cases.
This is misleading, because Cygwin binaries are a subset of the binaries
running on Windows. When building something with MinGW, the resulting
binary has nothing to do with Cygwin. Cygwin binaries are only special
in that they are Windows binaries that link to the cygwin1.dll library
(if my understanding is correct).
Looking at i386-cygwin-tdep.c, we can see that GDB does nothing
different when dealing with Cygwin binaries versus non-Cygwin Windows
binaries. However, there is at least one known bug which would require
us to make a distinction between the two OS ABIs, and that is the size
of the built-in "long" type on x86-64. On native Windows, this is 4,
whereas on Cygwin it's 8.
So, this patch adds a new OS ABI, "Windows", and makes GDB use it for
i386 and x86-64 PE executables, instead of the "Cygwin" OS ABI. A
subsequent patch will improve the OS ABI detection so that GDB
differentiates the non-Cygwin Windows binaries from the Cygwin Windows
binaries, and applies the "Cygwin" OS ABI for the latter.
The default OS ABI remains "Cygwin" for the GDBs built with a Cygwin
target.
I've decided to split the i386_cygwin_osabi_sniffer function in two,
I think it's cleaner to have a separate sniffer for Windows binaries and
Cygwin cores, each checking one specific thing.
gdb/ChangeLog:
* osabi.h (enum gdb_osabi): Add GDB_OSABI_WINDOWS.
* osabi.c (gdb_osabi_names): Add "Windows".
* i386-cygwin-tdep.c (i386_cygwin_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-i386".
(i386_cygwin_core_osabi_sniffer): New function, extracted from
i386_cygwin_osabi_sniffer.
(_initialize_i386_cygwin_tdep): Register OS ABI
GDB_OSABI_WINDOWS for i386.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-x86-64".
(_initialize_amd64_windows_tdep): Register OS ABI GDB_OSABI_WINDOWS
for x86-64.
* configure.tgt: Use GDB_OSABI_WINDOWS as the default OS ABI
when the target matches '*-*-mingw*'.
I think it makes sense to have it there instead of in the catch-all
defs.h.
gdb/ChangeLog:
* defs.h (enum gdb_osabi): Move to...
* osabi.h (enum gdb_osabi): ... here.
* gdbarch.sh: Include osabi.h in gdbarch.h.
* gdbarch.h: Re-generate.
If I generate two Windows PE executables, one 32 bits and one 64 bits:
$ x86_64-w64-mingw32-gcc test.c -g3 -O0 -o test_64
$ i686-w64-mingw32-gcc test.c -g3 -O0 -o test_32
$ file test_64
test_64: PE32+ executable (console) x86-64, for MS Windows
$ file test_32
test_32: PE32 executable (console) Intel 80386, for MS Windows
When I load the 32 bits binary in my GNU/Linux-hosted GDB, the osabi is
correctly recognized as "Cygwin":
$ ./gdb --data-directory=data-directory -nx test_32
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
When I load the 64 bits binary in GDB, the osabi is incorrectly
recognized as "GNU/Linux":
$ ./gdb --data-directory=data-directory -nx test_64
(gdb) show osabi
The current OS ABI is "auto" (currently "GNU/Linux").
The 32 bits one gets recognized by the i386_cygwin_osabi_sniffer
function, by its target name:
if (strcmp (target_name, "pei-i386") == 0)
return GDB_OSABI_CYGWIN;
The target name for the 64 bits binaries is "pei-x86-64". It doesn't
get recognized by any osabi sniffer, so GDB falls back on its default
osabi, "GNU/Linux".
This patch adds an osabi sniffer function for the Windows 64 bits
executables in amd64-windows-tdep.c. With it, the osabi is recognized
as "Cygwin", just like with the 32 bits binary.
Note that it may seems strange to have a binary generated by MinGW
(which has nothing to do with Cygwin) be recognized as a Cygwin binary.
This is indeed not accurate, but at the moment GDB uses the Cygwin for
everything Windows. Subsequent patches will add a separate "Windows" OS
ABI for Windows binaries that are not Cygwin binaries.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): New
function.
(_initialize_amd64_windows_tdep): Register osabi sniffer.
Test-case gdb.base/gdb-caching-proc.exp tests whether procs declared using
gdb_caching_proc give the same results when called more than once.
While this tests consistency of the procs in the context of that test-case, it
doesn't test consistency across the call sites.
Add a local variable cache_verify to proc gdb_do_cache, that can be set to 1
to verify gdb_caching_proc consistency across the call sites.
Likewise, add a local variable cache_verify_proc to set to the name of the
gdb_caching_proc to verify. This can f.i. be used when changing an existing
proc into a gdb_caching_proc.
Tested on x86_64-linux, with cache_verify set to both 0 and 1.
gdb/testsuite/ChangeLog:
2020-03-16 Tom de Vries <tdevries@suse.de>
* lib/cache.exp (gdb_do_cache): Add and handle local variables
cache_verify and cache_verify_proc.
This extracts code reading symbol tables into a common function that
tidies up after errors. I've also changed an error reporting multiple
string tables to an error on multiple symbol tables.
* readelf.c (get_symbols): New function.
(process_relocs, ia64_process_unwind, hppa_process_unwind),
(arm_process_unwind, get_symbol_for_build_attribute): Use it.
* unwind-ia64.c (unw_decode_uleb128): Prevent overlarge shifts.
Detect shift overflows and check that terminating byte is found.
Print an error on a bad uleb128.
* vms-alpha.c (dst_restore_location): Validate index into
dst_ptr_offsets array before accessing. Return status.
(dst_retrieve_location): Similarly, making "loc" parameter a
pointer to return value.
(_bfd_vms_slurp_etir): Update calls to above functions.
Since commit a2fedca99c "Implement 'set/show exec-file-mismatch'.", I see the
following regression on openSUSE Leap 15.1:
...
FAIL: gdb.server/solib-list.exp: non-stop 0: target remote \
(got interactive prompt)
FAIL: gdb.server/solib-list.exp: non-stop 1: target remote \
(got interactive prompt)
...
The first FAIL in more detail:
...
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile
target remote localhost:2346
Remote debugging using localhost:2346
warning: Mismatch between current exec-file /data/gdb_versions/devel/build/\
gdb/testsuite/outputs/gdb.server/solib-list/solib-list
and automatically determined exec-file /lib64/ld-2.26.so
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/lib64/ld-2.26.so"? (y or n) n
warning: loading /lib64/ld-2.26.so Not confirmed.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. \
Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading /lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /lib64/.debug/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote \
target...
Reading /data/gdb_versions/devel/install/lib64/debug//lib64/\
ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading target:/data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
(No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)
0x00007ffff7dd7ea0 in ?? ()
(gdb) FAIL: gdb.server/solib-list.exp: non-stop 0: target remote (got \
interactive prompt)
...
The commit introduces the "Load new symbol table from" question, and
gdb_test_multiple defaults to answering "no" and reporting the
"got interactive prompt" FAIL.
This FAIL is not seen on f.i. debian 10.2. The difference originates from the
fact that the solib-list executable has debug-info in the openSUSE case, while
it doesn't in the debian case.
We can prevent the failure on openSUSE by stripping the executable from
debug-info:
...
+ exec strip --strip-debug ${binfile}
...
The difference in behaviour is a bug or improvement opportunity in the
exec-file-mismatch, filed as PR25475.
This patch fixes the FAIL by handling the question in the test-case.
Tested on x86_64-linux.
Tested on x86_64-linux with the gdbserver part of the patch introducing the
test-case reverted to ensure that this still FAILs.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.server/solib-list.exp: Handle
'Load new symbol table from "/lib64/ld-2.26.so"? (y or n)'.
When running test-case gdb.base/maint.exp with check-read1, I run into:
...
FAIL: gdb.base/maint.exp: (timeout) maint print objfiles
...
The FAIL happens because command output contains long lines like this:
...
file1 at $hex, file2 at $hex, ..., $file$n at $hex,
...
F.i., such a line for libc.so.debug contains 82000 chars.
Fix this this by reading long lines bit by bit.
Also, replace the testing of the command output formulated using a gdb_send
combined with gdb_expect-in-a-loop, with a regular gdb_test_multiple with
exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.base/maint.exp: Use exp_continue in long lines for "maint print
objfiles".
A user noticed that "watch -location" would fail with a "restrict"
pointer. The issue here is that if the DWARF mentions "restrict", gdb
will put this into the type name -- but then the C parser will not be
able to parse this type.
This patch adds support for "restrict" and "_Atomic" to the C parser.
C++ doesn't have "restrict", but does have some GCC extensions. The
type printer is changed to handle this difference as well, so that
watch expressions will work properly.
gdb/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* c-typeprint.c (cp_type_print_method_args): Print "__restrict__"
for C++.
(c_type_print_modifier): Likewise. Add "language" parameter.
(c_type_print_varspec_prefix, c_type_print_base_struct_union)
(c_type_print_base_1): Update.
* type-stack.h (enum type_pieces) <tp_atomic, tp_restrict>: New
constants.
* type-stack.c (type_stack::insert): Handle tp_atomic and
tp_restrict.
(type_stack::follow_type_instance_flags): Likewise.
(type_stack::follow_types): Likewise. Merge type-following code.
* c-exp.y (RESTRICT, ATOMIC): New tokens.
(space_identifier, cv_with_space_id)
(const_or_volatile_or_space_identifier_noopt)
(const_or_volatile_or_space_identifier): Remove.
(single_qualifier, qualifier_seq_noopt, qualifier_seq): New
rules.
(ptr_operator, typebase): Update.
(enum token_flag) <FLAG_C>: New constant.
(ident_tokens): Add "restrict", "__restrict__", "__restrict", and
"_Atomic".
(lex_one_token): Handle FLAG_C.
gdb/testsuite/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* gdb.base/cvexpr.exp: Add test for _Atomic and restrict.
When running test-case gdb.mi/mi-fortran-modules.exp with check-read1, I run
into:
...
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions (timeout)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \
--name _all (unexpected output)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \
--module mod[123] (unexpected output)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-variables \
(unexpected output)
...
Fix this by using exp_continue.
Tested on x86_64, using make target check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-fortran-modules.exp: Use exp_continue.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* m68k-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* m68k-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* m68k-bsd-nat.c (m68k_bsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* m68k-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* m68k-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* alpha-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* alpha-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* alpha-bsd-nat.c (alpha_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* alpha-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* alpha-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
When running test-case gdb.threads/attach-many-short-lived-threads.exp with
check-read1, I ran into:
...
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: \
no new threads (timeout)
...
Fix this by rewriting the gdb_test_multiple call using -lbl and exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.threads/attach-many-short-lived-threads.exp: Read "info threads"
result in line-by-line fashion.
gdb/ChangeLog:
* arm-nbsd-nat.c (arm_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* arm-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
NetBSD ptrace(2) PT_GETDBREGS/PT_SETDBREGS accepts thread id (LWP)
as the 4th argument for threads.
gdb/ChangeLog:
* x86-bsd-nat.c (x86bsd_dr_get): New variable lwp and pass
it to the ptrace call.
* x86-bsd-nat.c (x86bsd_dr_set): Likewise.
ptrace(2) PT_GETREGS/PT_SETREGS accepts thread id (LWP) as the 4th
argument for threads.
gdb/ChangeLog:
* vax-bsd-nat.c (vaxbsd_supply_gregset): New variable lwp and pass
it to the ptrace call.
* vax-bsd-nat.c (vaxbsd_collect_gregset): Likewise.
gdb/ChangeLog:
* vax-bsd-nat.c (vax_bsd_nat_target): Inherit from nbsd_nat_target
instead of inf_ptrace_target.
* vax-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* mips-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* ppc-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* vax-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
In git commit fd486f32d1 I put some static variables used by
get_symbol_for_build_attribute in a file scope ba_cache struct. This
was to prevent leaks in get_symbol_for_build_attribute, and to tidy up
before readelf exited. The patch wasn't quite right though. When
readelf processes more than one file it was possible to double free
arrays allocated in get_symbol_for_build_attribute.
* readelf.c (process_file): Clean ba_cache.
When running testcase gdb.cp/step-and-next-inline.exp, I get:
...
Running src/gdb/testsuite/gdb.cp/step-and-next-inline.exp ...
gdb compile failed, g++: error: unrecognized debug output level \
'statement-frontiers'
gdb compile failed, g++: error: unrecognized debug output level \
'statement-frontiers'
=== gdb Summary ===
# of untested testcases 2
...
Fix this by using a new gdb_caching_proc supports_statement_frontiers.
Tested on x86_64-linux, with gcc 7.5.0 (which does not support
-gstatement-frontiers) and with gcc 8.4.0 (which does support
-gstatement-frontiers).
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (supports_statement_frontiers): New proc.
* gdb.cp/step-and-next-inline.exp: Use supports_statement_frontiers.
With test-case gdb.base/printcmds.exp, I run into:
...
(gdb) print teststring2^M
$563 = (charptr) "more contents"^M
(gdb) FAIL: gdb.base/printcmds.exp: print teststring2
...
The corresponding test is:
...
gdb_test "print teststring2" " = (charptr) \"more contents\""
...
Fix the FAIL by adding the missing quoting for the parentheses around charptr.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.base/printcmds.exp: Add missing quoting for "print
teststring2".
This test XPASSes on the generic ELF targets, so adjusting. I also
made xtensa an xfail instead of a skip, since skip is hiding some
nastiness.
* testsuite/ld-elf/non-contiguous.d: Don't xfail generic ELF
targets. Don't skip xtensa, xfail instead.
After the ld non-contiguous memory support my regen of bfd-in2.h
didn't match exactly what was committed, so I took the opportunity to
line up all the comments.
* section.c (BFD_FAKE_SECTIONS): Formatting.
* bfd-in2.h: Regenerate.
This changes the extension language pretty-printers to use the value
API.
Note that new functions were needed, for both Guile and Python.
Currently both languages always wrap values by removing the values
from the value chain. This makes sense to avoid strange behavior with
watchpoints, and to avoid excessive memory use. However, when
printing, it's important to leave the passed-in value untouched, in
case pretty-printing does nothing -- that way the caller can still
access it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Update.
* python/python-internal.h (gdbpy_apply_val_pretty_printer): Take
a struct value.
(value_to_value_object_no_release): Declare.
* python/py-value.c (value_to_value_object_no_release): New
function.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Take a
struct value.
* guile/scm-value.c (vlscm_scm_from_value_no_release): New
function.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Take
a struct value.
* guile/guile-internal.h (vlscm_scm_from_value_no_release):
Declare.
(gdbscm_apply_val_pretty_printer): Take a struct value.
* extension.h (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension.c (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension-priv.h (struct extension_language_ops)
<apply_val_pretty_printer>: Take a struct value.
* cp-valprint.c (cp_print_value): Create a struct value.
(cp_print_value): Update.
This converts print_field_values to use the value-based API, by having
it call common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (print_field_values): Call common_val_print.
This adds ada_value_print_array, a value-based analogue of
ada_val_print_array. It also removes some unused parameters from a
couple of helper functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (val_print_packed_array_elements): Remove
bitoffset and val parameters. Call common_val_print.
(ada_val_print_string): Remove offset, address, and original_value
parameters.
(ada_val_print_array): Update.
(ada_value_print_array): New function.
(ada_value_print_1): Call it.
This converts ada_value_print to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print): Use common_val_print.
This converts ada_val_print_ref to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_ref): Use common_val_print.
This adds ada_value_print_num, a value-based analogue of
ada_val_print_num.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_num): New function.
(ada_value_print_1): Use it.
This rewrites the TYPE_CODE_FLT case in ada_value_print_1 to be purely
value-based.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_1) <TYPE_CODE_FLT>: Rewrite.
This adds ada_value_print_ptr, a value-based analogue of
ada_val_print_ptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_ptr): New function.
(ada_value_print_1): Use it.
This rewrites ada_value_print_inner, introducing a new
ada_value_print_1, an analogue of ada_val_print_1. Because it was
simple to do, this also converts ada_val_print_gnat_array to be
valued-based and updates the uses.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_gnat_array): Take a struct value;
call common_val_print.
(ada_val_print_1): Update.
(ada_value_print_1): New function.
(ada_value_print_inner): Rewrite.
