I looked at all the calls to add_prefix_cmd, and replaced them with
calls to add_basic_prefix_cmd or add_show_prefix_cmd when appropriate.
This makes gdb's command language a bit more regular. I don't think
there's a significant downside.
Note that this patch removes a couple of tests. The removed ones are
completely redundant.
gdb/ChangeLog
2020-05-03 Tom Tromey <tom@tromey.com>
* breakpoint.c (catch_command, tcatch_command): Remove.
(_initialize_breakpoint): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(set_breakpoint_cmd, show_breakpoint_cmd): Remove
* utils.c (set_internal_problem_cmd, show_internal_problem_cmd):
Remove.
(add_internal_problem_command): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* mips-tdep.c (set_mipsfpu_command): Remove.
(_initialize_mips_tdep): Use add_basic_prefix_cmd.
* dwarf2/index-cache.c (set_index_cache_command): Remove.
(_initialize_index_cache): Use add_basic_prefix_cmd.
* memattr.c (dummy_cmd): Remove.
(_initialize_mem): Use add_basic_prefix_cmd, add_show_prefix_cmd.
* tui/tui-win.c (set_tui_cmd, show_tui_cmd): Remove.
(_initialize_tui_win): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cli/cli-logging.c (set_logging_command): Remove.
(_initialize_cli_logging): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(show_logging_command): Remove.
* target.c (target_command): Remove.
(add_target): Use add_basic_prefix_cmd.
gdb/testsuite/ChangeLog
2020-05-03 Tom Tromey <tom@tromey.com>
* gdb.base/sepdebug.exp: Remove "catch" test.
* gdb.base/break.exp: Remove "catch" test.
* gdb.base/default.exp: Update expected output.
The function info_command has disappeared, so this breakpoint does not
work anymore.
"info_command" was a function for the prefix command "info",
giving the list of "info" subcommands.
It is not very clear what the removed breakpoint and its associated
command list was supposed to do.
Removed and pushed as obvious, after discussion with Tom.
Report LWP CREATE and LWP EXIT events and setup this on post_attach()
and post_startup_inferior().
Stop reinitializing the list of recognized threads in update_thread_list().
Handle LWP CREATE and EXIT events in nbsd_nat_target::wait().
gdb/ChangeLog:
* nbsd-nat.c (nbsd_enable_proc_events)
(nbsd_nat_target::post_startup_inferior): Add.
(nbsd_nat_target::post_attach): Call `nbsd_enable_proc_events'.
(nbsd_nat_target::update_thread_list): Rewrite.
(nbsd_nat_target::wait): Handle "PTRACE_LWP_EXIT" and
"PTRACE_LWP_CREATE".
* nbsd-nat.h (nbsd_nat_target::post_startup_inferior): Add.
This reverts commit 84ed7a4725.
The problem that the commit attempts to address has already been fixed in
commit 770479f223 "gdb: Fix toplevel types with -fdebug-types-section".
The commit itself is superfluous because it sets list_in_scope at a point that
it's already set (by start_symtab).
"frame" and "f" are created twice by stack.c _initialize_stack.
Remove the second creation.
Regression tested on amd64/Debian.
2020-04-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* stack.c (_initialize_stack): Remove duplicated creation
of "frame" command and "f" alias.
Sizes of stubbed types are calculated on demand in check_typedef, so the
same must also be done for arrays of stubbed types.
A stubbed type is usually a structure that has only been forward declared,
but can also happen if the structure has a virtual function that's not
inline in the class definition.
For these stubbed types, the size must be recalculated once the full
definition is available.
gdb/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/18706
* gdbtypes.c (check_typedef): Calculate size of array of
stubbed type.
gdb/testsuite/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/18706
* gdb.cp/stub-array-size.cc: New test.
* gdb.cp/stub-array-size.exp: New file.
* gdb.cp/stub-array-size.h: New test.
* gdb.cp/stub-array-size2.cc: New test.
Non-static member functions for Windows 32bit programs need the thiscall
calling convention, so the 'this' pointer needs to be passed in ECX.
gdb/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/15559
* i386-tdep.c (i386_push_dummy_call): Call
i386_thiscall_push_dummy_call.
(i386_thiscall_push_dummy_call): New function.
* i386-tdep.h (i386_thiscall_push_dummy_call): Declare.
* i386-windows-tdep.c (i386_windows_push_dummy_call): New function.
(i386_windows_init_abi): Call set_gdbarch_push_dummy_call.
shellcheck reports:
In gdbarch.sh line 53:
while IFS='' read line
^--^ SC2162: read without -r will mangle backslashes.
See the rationale at [1]. In our case, we actually want the backslashes
to be interpreted and removed. Silence the warning using a directive.
[1] https://github.com/koalaman/shellcheck/wiki/SC2162
gdb/ChangeLog:
* gdbarch.sh (do_read): Add shellcheck disable directive for
warning SC2162.
Fix all instances of this kind of warning:
In gdbarch.sh line 96:
m ) staticdefault="${predefault}" ;;
^-----------^ SC2154: predefault is referenced but not assigned.
These warnings appear because we are doing something a bit funky when reading
the gdbarch fields. These variables are not assigned explicitly, but
using some `eval` commands.
I don't think there is so much we can fix about those warnings. To
silence them, I've changed `${foo}` to `${foo:-}`. This tells the shell
to substitute with an empty string if `foo` is not defined. This
retains the current behavior, but the warnings go away.
gdb/ChangeLog:
* gdbarch.sh: Use ${foo:-} where shellcheck would report a
"referenced but not assigned" warning.
shellcheck reports:
In gdbarch.sh line 139:
fallbackdefault="0"
^-------------^ SC2034: fallbackdefault appears unused. Verify use (or export if used externally).
Indeed, the `fallbackdefault` variable appears to be unused, remove the
code that sets it.
gdb/ChangeLog:
* gdbarch.sh: Remove code that sets fallbackdefault.
Fix all warnings of this type:
In gdbarch.sh line 1238:
if [ "x${invalid_p}" = "x0" -a -n "${postdefault}" ]
^-- SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
See the rationale here [1].
[1] https://github.com/koalaman/shellcheck/wiki/SC2166
gdb/ChangeLog:
* gdbarch.sh: Use shell operators && and || instead of
-a and -o.
Fix all instances of:
In gdbarch.sh line 2195:
printf " `echo "$function" | sed -e 's/./ /g'` %s %s)\n" "$returntype" "$function"
^-- SC2006: Use $(...) notation instead of legacy backticked `...`.
Did you mean:
printf " $(echo "$function" | sed -e 's/./ /g') %s %s)\n" "$returntype" "$function"
See here [1] for the rationale.
[1] https://github.com/koalaman/shellcheck/wiki/SC2006
gdb/ChangeLog:
* gdbarch.sh: Use $(...) instead of `...`.
Fix all instances of:
In gdbarch.sh line 31:
if test ! -r ${file}
^-----^ SC2086: Double quote to prevent globbing and word splitting.
Did you mean:
if test ! -r "${file}"
Note that some instances of these are in text that is eval'ed. I'm
pretty sure that things could go wrong during the eval too, but that's
not something shellcheck can check.
gdb/ChangeLog:
* gdbarch.sh: Use double quotes around variables.
Fix all instances of this:
In gdbarch.sh line 2182:
printf " gdb_assert (!(${invalid_p}));\n"
^-- SC2059: Don't use variables in the printf format string. Use printf "..%s.." "$foo".
... by doing exactly as the message suggests.
The rationale explained here [1] makes sense, if there happens to be a
format specifier in text substituted for the variable, the printf won't
do what we expect.
[1] https://github.com/koalaman/shellcheck/wiki/SC2059
gdb/ChangeLog:
* gdbarch.sh: Use %s with printf, instead of variables in the
format string.
PR ada/25875 concerns a gdb crash when gdb.ada/arr_enum_idx_w_gap.exp
is run using the .debug_types board.
The problem turns out to be caused by weird compiler output. In this
test, the compiler emits a top-level type that refers to an
enumeration type which is nested in a function. However, this
function is just a declaration.
This results in gdb calling read_enumeration_type for the enum type,
but process_enumeration_scope is never called, yielding an enum with
no fields. This causes the crash.
This patch fixes the problem by arranging to create the enum fields in
read_enumeration_type.
Tested on x86-64 Fedora 30.
gdb/ChangeLog
2020-04-29 Tom Tromey <tromey@adacore.com>
PR ada/25875:
* dwarf2/read.c (update_enumeration_type_from_children): Compute
type fields here.
(read_enumeration_type): Call
update_enumeration_type_from_children later. Update comments.
(process_enumeration_scope): Don't create type fields.
The syscall literal names are not stable on NetBSD and can change
once a syscall is versioned. Thus these names are internal to the
system and in GDB mostly descriptive, not intended to be a stable
interface with fixed names across GDB and NetBSD versions to track
certain syscalls.
gdb/ChangeLog:
* nbsd-tdep.c: Include "xml-syscall.h".
(nbsd_init_abi): Call `set_xml_syscall_file_name'.
Implement the following events:
- single step (TRAP_TRACE)
- software breakpoint (TRAP_DBREG)
- exec() (TRAP_EXEC)
- syscall entry/exit (TRAP_SCE / TRAP_SCX)
Add support for NetBSD specific ::wait () and ::resume ().
Instruct the generic code that exec and syscall events are supported.
Define an empty nbsd_get_syscall_number as it is prerequisite for
catching syscall entry and exit events, even if it is unused.
This function is used to detect whether the gdbarch supports the
'catch syscall' feature.
gdb/ChangeLog:
* nbsd-nat.c: Include "sys/wait.h".
(nbsd_resume, nbsd_nat_target::resume, nbsd_wait)
(nbsd_nat_target::wait, nbsd_nat_target::insert_exec_catchpoint)
(nbsd_nat_target::remove_exec_catchpoint)
(nbsd_nat_target::set_syscall_catchpoint): Add.
* nbsd-nat.h (nbsd_nat_target::resume, nbsd_nat_target::wait)
(nbsd_nat_target::insert_exec_catchpoint)
(nbsd_nat_target::remove_exec_catchpoint)
(nbsd_nat_target::set_syscall_catchpoint): Add.
* nbsd-tdep.c (nbsd_get_syscall_number): Add.
(nbsd_init_abi): Call `set_gdbarch_get_syscall_number' and pass
`nbsd_get_syscall_number'.
print_block_frame_labels has been commented out since 2010.
I don't think we need it; this patch removes it.
2020-04-29 Tom Tromey <tom@tromey.com>
* stack.c (print_block_frame_labels): Remove.
Currently, printing with array pretty formatting makes the output actually
less readable than without:
(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 = { {1,
2,
3},
{4,
5,
6}}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 = {[0] = {[0] = 1,
[1] = 2,
[2] = 3},
[1] = {[0] = 4,
[1] = 5,
[2] = 6}}
These changes now also put the first element and the array end bracket on a new
line, similar to the structure pretty formatter:
(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 = {
{
1,
2,
3
},
{
4,
5,
6
}
}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 = {
[0] = {
[0] = 1,
[1] = 2,
[2] = 3
},
[1] = {
[0] = 4,
[1] = 5,
[2] = 6
}
}
gdb/ChangeLog:
2020-04-29 Hannes Domani <ssbssa@yahoo.de>
PR gdb/17320
* ada-valprint.c (val_print_packed_array_elements): Move array
end bracket to new line.
(ada_val_print_string): Remove extra spaces before first array
element.
* c-valprint.c (c_value_print_array): Likewise.
* m2-valprint.c (m2_print_array_contents): Likewise.
(m2_value_print_inner): Likewise.
* p-valprint.c (pascal_value_print_inner): Likewise.
* valprint.c (generic_val_print_array): Likewise.
(value_print_array_elements): Move first array element and array
end bracket to new line.
gdb/testsuite/ChangeLog:
2020-04-29 Hannes Domani <ssbssa@yahoo.de>
PR gdb/17320
* gdb.base/pretty-array.c: New test.
* gdb.base/pretty-array.exp: New file.
With target board debug-types, we have:
...
FAIL: gdb.cp/cpexprs.exp: list policy1::function
...
This is a regression triggered by commit 770479f223 "gdb: Fix toplevel types
with -fdebug-types-section".
However, the FAIL is caused by commit 4dedf84da9 "Change
decode_compound_collector to use std::vector" which changes a VEC_iterate loop
into a range loop:
...
- for (ix = 0; VEC_iterate (symbolp, sym_classes, ix, sym); ++ix)
+ unsigned int ix = 0;
+ for (const auto &sym : *sym_classes)
...
but fails to ensure that the increment of ix happens every iteration.
Fix this by calculating the index variable at the start of the loop body:
...
for (const auto &elt : *sym_classes)
{
unsigned int ix = &elt - &*sym_classes->begin ();
...
Tested on x86_64-linux, with native and target board debug-types.
gdb/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
PR symtab/25889
* linespec.c (find_method): Fix ix calculation.
gdb/testsuite/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
PR symtab/25889
* gdb.cp/cpexprs.exp: Adapt for inclusion.
* gdb.cp/cpexprs-debug-types.exp: New file. Set -fdebug-types-section
and include cpexprs.exp.
All platforms on NetBSD use a shared system call table, so use a
single XML file to describe the system calls available on each NetBSD
platform.
gdb/ChangeLog:
* syscalls/update-netbsd.sh: New file.
* syscalls/netbsd.xml: Regenerate.
* data-directory/Makefile.in: Register `netbsd.xml' in
`SYSCALLS_FILES'
shellcheck reports:
In update-freebsd.sh line 72:
}' $1 >> freebsd.xml.tmp
^-- SC2086: Double quote to prevent globbing and word splitting.
Did you mean:
}' "$1" >> freebsd.xml.tmp
For more information:
https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
Add double quotes to fix it.
gdb/ChangeLog:
* syscalls/update-freebsd.sh: Add double quotes.
Now that Python code can create TUI windows, it seemed appropriate to
allow Python commands to appear in the "TUI" help class. This patch
adds this capability.
gdb/ChangeLog
2020-04-28 Tom Tromey <tom@tromey.com>
* NEWS: Update.
* python/py-cmd.c (gdbpy_initialize_commands): Add COMMAND_TUI.
(cmdpy_init): Allow class_tui.
gdb/doc/ChangeLog
2020-04-28 Tom Tromey <tom@tromey.com>
* python.texi (Commands In Python): Document gdb.COMMAND_TUI.
When building with g++ 4.8, we get this error (just an excerpt, because
g++ outputs a very long error message):
CXX dwarf2/read.o
...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:14616:31: required from here
/usr/include/c++/4.8/bits/hashtable_policy.h:1070:12: error: invalid use of incomplete type ‘struct std::hash<sect_offset>’
struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2,
This is the same problem and fix as in commit f23f598e28 ("[gdb] Fix
build breaker with gcc 4.8"). Pass an explicit hash function rather
than relying on the default std::hash<sect_offset>.
gdb/ChangeLog:
PR gdb/25881
* dwarf2/read.c (offset_map_type): Use
gdb:hash_enum<sect_offset> as hash function.
Consider a test-case with sources 36.c:
...
struct s { int i; };
extern void f (void);
int main (void) {
struct s a;
f ();
return 0;
}
...
and 36b.c:
...
struct s { int j; };
void f (void) {
struct s b;
}
...
compiled like this:
...
$ gcc 36.c 36b.c -g
...
It contains DWARF like this:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : 36.c
<1><f4>: Abbrev Number: 2 (DW_TAG_structure_type)
<f5> DW_AT_name : s
<2><fe>: Abbrev Number: 3 (DW_TAG_member)
<ff> DW_AT_name : i
<1><110>: Abbrev Number: 5 (DW_TAG_subprogram)
<111> DW_AT_name : main
<2><12d>: Abbrev Number: 6 (DW_TAG_variable)
<12e> DW_AT_name : a
<132> DW_AT_type : <0xf4>
<0><146>: Abbrev Number: 1 (DW_TAG_compile_unit)
<14c> DW_AT_name : 36b.c
<1><168>: Abbrev Number: 2 (DW_TAG_structure_type)
<169> DW_AT_name : s
<2><172>: Abbrev Number: 3 (DW_TAG_member)
<173> DW_AT_name : j
<1><184>: Abbrev Number: 5 (DW_TAG_subprogram)
<185> DW_AT_name : f
<2><19b>: Abbrev Number: 6 (DW_TAG_variable)
<19c> DW_AT_name : b
<1a0> DW_AT_type : <0x168>
...
And when printing "struct s", we get first a random one (with int j), and then
context-specific ones (with int i in main, and int j in f):
...
$ gdb -batch a.out \
-ex "ptype struct s" \
-ex start \
-ex "ptype struct s" \
-ex "break f" -ex continue \
-ex "ptype struct s" \
| grep "int [ij];"
int j;
int i;
int j;
...
Same for -readnow.
However, if we use -fdebug-types-section:
...
$ gcc 36.c 36b.c -g -fdebug-types-section
...
we get:
...
$ gdb ... | grep "int [ij];"
int j;
int i;
int i;
$ gdb -readnow ... | grep "int [ij];"
int j;
int j;
int j;
...
This is due to the fact that both "struct s" DIEs have been moved to the
.debug_types section:
...
Compilation Unit @ offset 0x0:
Signature: 0xfd1462823bb6f7b7
<0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
<1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e> DW_AT_name : s
<2><27>: Abbrev Number: 3 (DW_TAG_member)
<28> DW_AT_name : i
Compilation Unit @ offset 0x3a:
Signature: 0x534310fbefba324d
<0><51>: Abbrev Number: 1 (DW_TAG_type_unit)
<1><57>: Abbrev Number: 2 (DW_TAG_structure_type)
<58> DW_AT_name : s
<2><61>: Abbrev Number: 3 (DW_TAG_member)
<62> DW_AT_name : j
...
and there's no longer a "struct s" DIE in the 36.c and
and 36b.c CUs to specify which "struct s" belongs in the CU. This is gcc
PR90232.
However, using a tentative patch for gcc that adds these DIEs (according to
DWARF standard: If the complete declaration of a type has been placed in a
separate type unit, an incomplete declaration of that type in the compilation
unit may provide the unique 64-bit signature of the type using a
DW_AT_signature attribute):
...
<0><d2>: Abbrev Number: 5 (DW_TAG_compile_unit)
<d8> DW_AT_name : 36.c
+ <1><f4>: Abbrev Number: 6 (DW_TAG_structure_type)
+ <f5> DW_AT_name : s
+ <f7> DW_AT_signature : signature: 0xfd1462823bb6f7b7
+ <ff> DW_AT_declaration : 1
<0><13c>: Abbrev Number: 5 (DW_TAG_compile_unit)
<142> DW_AT_name : 36b.c
+ <1><15e>: Abbrev Number: 6 (DW_TAG_structure_type)
+ <15f> DW_AT_name : s
+ <161> DW_AT_signature : signature: 0x534310fbefba324d
+ <169> DW_AT_declaration : 1
...
still does not help, because they're declarations, so new_symbol is not called
for them in process_structure_scope.
Fix this by calling new_symbol for these decls.
Build and tested on x86_64-linux.
Also tested with target board enabling by default -fdebug-types-section
-gdwarf-4, and with gcc with aforementioned tentative patch. In this
configuration, the patch reduces number of FAILs from 2888 to 238.
gdb/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (process_structure_scope): Add symbol for struct decl
with DW_AT_signature.
gdb/testsuite/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/main-foo.c: New test.
* gdb.dwarf2/struct-with-sig.exp: New file.
I recently stumbled on this code mentioning Linux kernel 2.6.25, and
thought it could be time for some spring cleaning (newer GDBs probably
don't need to supports 12-year old kernels). I then found that the
"legacy" case is probably broken anyway, which gives an even better
motivation for its removal.
In short, this patch removes the configure checks that check if
user_regs_struct contains the fs_base/gs_base fields and adjusts all
uses of the HAVE_STRUCT_USER_REGS_STRUCT_{FS,GS}_BASE macros. The
longer explanation/rationale follows.
Apparently, Linux kernels since 2.6.25 (that's from 2008) have been
reliably providing fs_base and gs_base as part of user_regs_struct.
Commit df5d438e33d7 in the Linux kernel [1] seems related. This means
that we can get these values by reading registers with PTRACE_GETREGS.
Previously, these values were obtained using a separate
PTRACE_ARCH_PRCTL ptrace call.
First, I'm not even sure the configure check was really right in the
first place.
The user_regs_struct used by GDB comes from
/usr/include/x86_64-linux-gnu/sys/user.h (or equivalent on other
distros) and is provided by glibc. glibc has had the fs_base/gs_base
fields in there for a very long time, at least since this commit from
2001 [2]. The Linux kernel also has its version of user_regs_struct,
which I think was exported to user-space at some point. It included the
fs_base/gs_base fields since at least this 2002 commit [3]. In any
case, my conclusion is that the fields were there long before the
aforementioned Linux kernel commit. The kernel commit didn't add these
fields, it only made sure that they have reliable values when obtained
with PTRACE_GETREGS.
So, checking for the presence of the fs_base/gs_base fields in struct
user_regs_struct doesn't sound like a good way of knowing if we can
reliably get the fs_base/gs_base values from PTRACE_GETREGS. My guess
is that if we were using that strategy on a < 2.6.25 kernel, things
would not work correctly:
- configure would find that the user_regs_struct has the fs_base/gs_base
fields (which are probided by glibc anyway)
- we would be reading the fs_base/gs_base values using PTRACE_GETREGS,
for which the kernel would provide unreliable values
Second, I have tried to see how things worked by forcing GDB to not use
fs_base/gs_base from PTRACE_GETREGS (forcing it to use the "legacy"
code, by configuring with
ac_cv_member_struct_user_regs_struct_gs_base=no ac_cv_member_struct_user_regs_struct_fs_base=no
Doing so breaks writing registers back to the inferior. For example,
calling an inferior functions gives an internal error:
(gdb) p malloc(10)
/home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408: internal-error: invalid i387 regnum 152
The relevant last frames where this error happens are:
#8 0x0000563123d262fc in internal_error (file=0x563123e93fd8 "/home/smarchi/src/binutils-gdb/gdb/i387-tdep.c", line=1408, fmt=0x563123e94482 "invalid i387 regnum %d") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
#9 0x0000563123047d0d in i387_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408
#10 0x0000563122c69e8a in amd64_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/amd64-tdep.c:3448
#11 0x0000563122c5e94c in amd64_linux_nat_target::store_registers (this=0x56312515fd10 <the_amd64_linux_nat_target>, regcache=0x5631269453f0, regnum=152) at /home/smarchi/src/binutils-gdb/gdb/amd64-linux-nat.c:335
#12 0x00005631234c8c80 in target_store_registers (regcache=0x5631269453f0, regno=152) at /home/smarchi/src/binutils-gdb/gdb/target.c:3485
#13 0x00005631232e8df7 in regcache::raw_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:765
#14 0x00005631232e8f0c in regcache::cooked_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:778
#15 0x00005631232e75ec in regcache::restore (this=0x5631269453f0, src=0x5631275eb130) at /home/smarchi/src/binutils-gdb/gdb/regcache.c:283
#16 0x0000563123083fc4 in infcall_suspend_state::restore (this=0x5631273ed930, gdbarch=0x56312718cf20, tp=0x5631270bca90, regcache=0x5631269453f0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9103
#17 0x0000563123081eed in restore_infcall_suspend_state (inf_state=0x5631273ed930) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9151
The problem seems to be that amd64_linux_nat_target::store_registers
calls amd64_native_gregset_supplies_p to know whether gregset provides
fs_base. When !HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE,
amd64_native_gregset_supplies_p returns false. store_registers
therefore assumes that it must be an "xstate" register. This is of
course wrong, and that leads to the failed assertion when
i387_collect_xsave doesn't recognize the register.
amd64_linux_nat_target::store_registers could probably be fixed to
handle this case, but I don't think it's worth it, given that it would
only be to support very old kernels.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5d438e33d7fc914ba9b6e0d6b019a8966c5fcc
[2] https://sourceware.org/git/?p=glibc.git;a=commit;h=c9cf6ddeebb7bb
[3] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=88e4bc32686ebd0b1111a94f93eba2d334241f68
gdb/ChangeLog:
* configure.ac: Remove check for fs_base/gs_base in
user_regs_struct.
* configure: Re-generate.
* config.in: Re-generate.
* amd64-nat.c (amd64_native_gregset_reg_offset): Adjust.
* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers,
amd64_linux_nat_target::store_registers, ps_get_thread_area, ): Adjust.
gdbserver/ChangeLog:
* configure.ac: Remove check for fs_base/gs_base in
user_regs_struct.
* configure: Re-generate.
* config.in: Re-generate.
* linux-x86-low.cc (x86_64_regmap, x86_fill_gregset,
x86_store_gregset): Adjust.
Commit 5939967b35 fixed inline
frame unwinding breakage for some targets (aarch64, riscv, s390...)
but regressed a few amd64 testcases related to tailcalls.
Given the following example situation...
Frame #-1 - sentinel frame
Frame # 0 - inline frame
Frame # 1 - normal frame
... suppose we're at level #1 and call into dwarf2_tailcall_sniffer_first.
We'll attempt to fetch PC, which used to be done via the gdbarch_unwind_pc call
(before 5939967b35), but now it is being handled
by the get_frame_register function.
gdbarch_unwind_pc will attempt to use frame #1's cache to retrieve information
about the PC. Here's where different architectures behave differently.
x86_64 will find a dwarf rule to retrieve PC from memory, at a CFA + offset
location. So the PC value is readily available and there is no need to
create a lazy value.
For aarch64 (and others), GCC doesn't emit an explicit location for PC, so we
eventually will find that PC is DWARF2_FRAME_REG_UNSPECIFIED. This is known
and is handled by GDB by assuming GCC really meant DWARF2_FRAME_REG_SAME_VALUE.
This means we'll attempt to fetch the register value from frame #0, via a call
to frame_unwind_got_register, which will trigger the creation of a lazy value
that requires a valid frame id for frame #0.
We don't have a valid id for frame #0 yet, so we assert.
Given the above, the following patch attempts to handle the situation without
being too hacky. We verify if the next frame is an inline frame and if its
frame id has been computed already. If it hasn't been computed yet, then we
use the safer get_frame_register function, otherwise we use the regular
gdbarch_unwind_pc hook.
gdb/ChangeLog:
2020-04-27 Luis Machado <luis.machado@linaro.org>
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Handle
problematic inline frame unwinding situation.
* frame.c (frame_id_computed_p): New function.
* frame.h (frame_id_computed_p): New prototype.
The class_pseudo constant is unused, so this removes it.
Tested by rebuilding.
gdb/ChangeLog
2020-04-26 Tom Tromey <tom@tromey.com>
* command.h (enum command_class) <class_pseudo>: Remove.
Remove unused PT_GET_PROCESS_STATE block. It used to be used
by OpenBSD, but it is now reimplemented independently in
obsd-nat.c.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_target::wait): Remove
`PT_GET_PROCESS_STATE' block.
Change-Id: I9b872df8517b658c0dfe889fc1e4a7009bc5c076
Now that symbol_get_demangled_name is only used by general_symbol_info
methods, and because these methods already check the symbol's language
to decide what to return, symbol_get_demangled_name is no longer
needed. This patch removes it.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* symtab.h (symbol_get_demangled_name): Don't declare.
* symtab.c (symbol_get_demangled_name): Remove.
(general_symbol_info::natural_name)
(general_symbol_info::demangled_name): Update.
PR rust/25025 notes that some Rust test cases fail.
Debugging gdb revealed that the Rust compiler emits different linkage
names that demangle to the same result. Enabling complaints when
reading the test case is enough to show it:
During symbol reading: Computed physname <generics::identity<f64>> does not match demangled <generics::identity> (from linkage <_ZN8generics8identity17h8540b320af6656d6E>) - DIE at 0x424 [in module /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.rust/generics/generics]
During symbol reading: Computed physname <generics::identity<u32>> does not match demangled <generics::identity> (from linkage <_ZN8generics8identity17hae302fad0c33bd7dE>) - DIE at 0x459 [in module /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.rust/generics/generics]
...
This patch changes the DWARF reader to prefer the computed physname,
rather than the output of the demangler, for Rust. This fixes the
bug.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
PR rust/25025:
* dwarf2/read.c (dwarf2_physname): Do not demangle for Rust.
The DWARF reader has had some odd code since the "physname" patches landed.
In particular, these patches caused PR symtab/12707; namely, they made
it so "set print demangle off" no longer works.
This patch attempts to fix the problem. It arranges to store the
linkage name on the symbol if it exists, and it changes the DWARF
reader so that the demangled name is no longer (usually) stored in the
symbol's "linkage name" field.
c-linkage-name.exp needed a tweak, because it started working
correctly. This conforms to what I think ought to happen, so this
seems like an improvement here.
compile-object-load.c needed a small change to use
symbol_matches_search_name rather than directly examining the linkage
name. Looking directly at the name does the wrong thing for C++.
There is still some name-related confusion in the DWARF reader:
* "physname" often refers to the logical name and not what I would
consider to be the "physical" name;
* dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and
return different strings -- but this seems like at least one name
too many. For example, Fortran requires dwarf2_full_name, but other
languages do not.
* To my surprise, dwarf2_physname prefers the form emitted by the
demangler over the one that it computes. This seems backward to me,
given that the partial symbol reader prefers the opposite, and it
seems to me that this choice may perform better as well.
I didn't attempt to clean up these things. It would be good to do,
but whenever I contemplate it I get caught up in dreams of truly
rewriting the DWARF reader instead.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
PR symtab/12707:
* dwarf2/read.c (add_partial_symbol): Use the linkage name if it
exists.
(new_symbol): Likewise.
* compile/compile-object-load.c (get_out_value_type): Use
symbol_matches_search_name.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
PR symtab/12707:
* gdb.python/py-symbol.exp: Update expected results for
linkage_name test.
* gdb.cp/print-demangle.exp: New file.
* gdb.base/c-linkage-name.exp: Fix test.
* gdb.guile/scm-symbol.exp: Update expected results for
linkage_name test.
As mentioned in another thread, there's currently no need to call
compute_and_set_names for partial symbols. Because the DWARF partial
symbol reader constructs demangled names, this call can only demangle
a name by mistake.
So, this patch changes the DWARF reader to simply set the linkage name
on the new symbol. This is equivalent to what was done before. There
should be no user-visible change from this patch, aside from gdb
speeding up a bit.
... there *should* be, but this regressed
dw2-namespaceless-anonymous.exp. However, upon examination, I think
that test is incorrect. It puts a mangled name into DW_AT_name, and
it puts the variable at the top level, not in a namespace. This isn't
what C++ compilers ought to do. So, this patch also updates the test
case.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (add_partial_symbol): Do not call
compute_and_set_names.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/dw2-namespaceless-anonymous.S: Remove.
* gdb.dwarf2/dw2-namespaceless-anonymous.c: New file.
* gdb.dwarf2/dw2-namespaceless-anonymous.exp: Use DWARF
assembler.
This changes the DWARF reader to use the new add_psymbol_to_list
overload. There should be no visible changes due to this patch.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (add_partial_symbol): Use new add_psymbol_to_list
overload.
This adds a new overload of add_psymbol_to_list. This one takes an
already constructed psymbol and adds it to the bcache and the
appropriate list.
This seemed cleaner than continuing to add parameters to the existing
add_psymbol_to_list, and is more in line with how full symbols are
constructed.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* psymtab.c (add_psymbol_to_bcache): Simplify calling convention.
(add_psymbol_to_list): New overload. Make old overload call new
one.
* psympriv.h (add_psymbol_to_list): New overload.
The full DIE reader checks that an attribute has a "string" form in
some spots, but the partial DIE reader does not. This patch brings
the two readers in sync for one specific case, namely when examining
the linkage name. This avoids regressions in an existing DWARF test
case.
A full fix for this problem would be preferable. An accessor like
DW_STRING should always check the form. However, I haven't attempted
that in this series.
Also the fact that the partial and full readers can disagree like this
is a design flaw.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (partial_die_info::read) <case
DW_AT_linkage_name>: Use value_as_string.
(dwarf2_string_attr): Use value_as_string.
* dwarf2/attribute.h (struct attribute) <value_as_string>: Declare
method.
* dwarf2/attribute.c (attribute::value_as_string): New method.
Two methods on general_symbol_info did not handle the language_rust
case. I don't think these problems can be noticed with the current
code (which is why the bugs went unnoticed), but a future patch will
change this.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* symtab.c (general_symbol_info::natural_name)
(general_symbol_info::demangled_name): Check for language_rust.
The DWARF reader has a special case to work around a bug in some
versions of the Rust compiler -- it ignores mangled names that contain
a "{" character.
I noticed that this check should probably be in dw2_linkage_name
rather than only in dwarf2_physname. The former is called in some
cases that the latter is not.
Also, I noticed that this work is not done for the partial DIE reader,
so this patch adds the check there as well.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dw2_linkage_name): Move Rust "{" hack here...
(dwarf2_physname): ... from here.
(partial_die_info::read): Add Rust "{" hack.
This changes symbol_set_demangled_name to be a method on
general_symbol_info, and updates the users.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* symtab.h (struct general_symbol_info) <set_demangled_name>: New
method.
(symbol_set_demangled_name): Don't declare.
* symtab.c (general_symbol_info::set_demangled_name): Rename from
symbol_set_demangled_name.
(general_symbol_info::set_language)
(general_symbol_info::compute_and_set_names): Update.
* minsyms.c (minimal_symbol_reader::install): Update.
* dwarf2/read.c (new_symbol): Update.
This changes the gdb Python API to add support for dynamic types. In
particular, this adds an attribute to gdb.Type, and updates some
attributes to reflect dynamic sizes and field offsets.
There's still no way to get the dynamic type from one of its concrete
instances. This could perhaps be added if needed.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python/py-type.c (convert_field): Handle
FIELD_LOC_KIND_DWARF_BLOCK.
(typy_get_sizeof): Handle TYPE_HAS_DYNAMIC_LENGTH.
(typy_get_dynamic): Nw function.
(type_object_getset): Add "dynamic".
* NEWS: Add entry.
gdb/doc/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python.texi (Types In Python): Document new features.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* gdb.ada/variant.exp: Add Python checks.
* gdb.rust/simple.exp: Add dynamic type checks.
The DWARF reader was updated to handle variant parts and some other
selected features for Ada; but the Ada "ptype" code was not touched.
This patch changes the Ada ptype code to handle the new types
properly.
Test cases for this and for some of the other code in this series are
in a separate patch.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (print_choices, print_variant_part)
(print_record_field_types_dynamic): New functions.
(print_record_field_types): Use print_record_field_types_dynamic.
In Ada, a field can have a variable offset. This patch adds support
for this case to gdb, using the existing dynamic type resolution code.
Doing just this, though, would break C++ virtual base handling.
It turns out that virtual base handling only worked by the ugliest of
hacks. In particular, the DWARF reader would call decode_locdesc for
a virtual base location. Here's an example of such an expression from
gdb's m-static test case:
<241> DW_AT_data_member_location: 6 byte block: 12 6 48 1c 6 22 (DW_OP_dup; DW_OP_deref; DW_OP_lit24; DW_OP_minus; DW_OP_deref; DW_OP_plus)
When examining this, decode_locdesc would treat DW_OP_deref as a no-op
and compute some answer (here, -24). This would be stored as the
offset.
Later, in gnu-v3-abi.c, the real offset would be computed by digging
around in the vtable.
This patch cleans up this area. In particular, it now evaluates the
location expression on demand.
Note there is a new FIXME in gnu-v3-abi.c. I think some of the
callers are incorrect here, and have only worked because this member
is unused. I will file a bug for this. I didn't fix this problem in
this series because I felt it was already too complex.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (handle_data_member_location): New overload.
(dwarf2_add_field): Use it.
(decode_locdesc): Add "computed" parameter. Update comment.
* gdbtypes.c (is_dynamic_type_internal): Also look for
FIELD_LOC_KIND_DWARF_BLOCK.
(resolve_dynamic_struct): Handle FIELD_LOC_KIND_DWARF_BLOCK.
* gdbtypes.c (is_dynamic_type_internal): Add special case for C++
virtual base classes.
* gnu-v3-abi.c (gnuv3_baseclass_offset): Handle
FIELD_LOC_KIND_DWARF_BLOCK.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* gdb.ada/variant.exp: Add dynamic field offset tests.
* gdb.ada/variant/pck.ads (Nested_And_Variable): New type.
* gdb.ada/variant/pkg.adb: Add new variables.
In Ada, a type with variant parts can have a variable length. This
patch adds support for this to gdb, by integrating the length
computation into the dynamic type resolution code.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_structure_type): Handle dynamic length.
* gdbtypes.c (is_dynamic_type_internal): Check
TYPE_HAS_DYNAMIC_LENGTH.
(resolve_dynamic_type_internal): Use TYPE_DYNAMIC_LENGTH.
* gdbtypes.h (TYPE_HAS_DYNAMIC_LENGTH, TYPE_DYNAMIC_LENGTH):
New macros.
(enum dynamic_prop_node_kind) <DYN_PROP_BYTE_SIZE>: New
constant.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* gdb.ada/variant.exp: New file
* gdb.ada/variant/pkg.adb: New file
* gdb.ada/variant/pck.adb: New file
This rewrites the existing variant part code to follow the new model
implemented in the previous patch. The old variant part code is
removed.
This only affects Rust for the moment. I tested this using various
version of the Rust compiler, including one that emits old-style enum
debuginfo, exercising the quirks code.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (struct variant_field): Rewrite.
(struct variant_part_builder): New.
(struct nextfield): Remove "variant" field. Add "offset".
(struct field_info): Add "current_variant_part" and
"variant_parts".
(alloc_discriminant_info): Remove.
(alloc_rust_variant): New function.
(quirk_rust_enum): Update.
(dwarf2_add_field): Set "offset" member. Don't handle
DW_TAG_variant_part.
(offset_map_type): New typedef.
(convert_variant_range, create_one_variant)
(create_one_variant_part, create_variant_parts)
(add_variant_property): New functions.
(dwarf2_attach_fields_to_type): Call add_variant_property.
(read_structure_type): Don't handle DW_TAG_variant_part.
(handle_variant_part, handle_variant): New functions.
(handle_struct_member_die): Use them.
(process_structure_scope): Don't handle variant parts.
* gdbtypes.h (TYPE_FLAG_DISCRIMINATED_UNION): Remove.
(struct discriminant_info): Remove.
(enum dynamic_prop_node_kind) <DYN_PROP_DISCRIMINATED>: Remove.
(struct main_type) <flag_discriminated_union>: Remove.
* rust-lang.c (rust_enum_p, rust_empty_enum_p): Rewrite.
(rust_enum_variant): Return int. Remove "contents". Rewrite.
(rust_print_enum, rust_print_struct_def, rust_evaluate_subexp):
Update.
* valops.c (value_union_variant): Remove.
* value.h (value_union_variant): Don't declare.
When evaluating a DWARF expression, the dynamic type resolution code
will pass in a buffer of bytes via the property_addr_info. However,
the DWARF expression evaluator will then proceed to read memory from
the inferior, even when the request could be filled from this buffer.
This, in turn, is a problem in some cases; and specifically when
trying to handle the Ada scenario of extracting a variable-length
value from a packed array. Here, the ordinary DWARF expression cannot
be directly evaluated, because the data may appear at some arbitrary
bit offset. So, it is unpacked into a staging area and then the
expression is evaluated -- using an address of 0.
This patch fixes the problem by arranging for the DWARF evaluator, in
this case, to prefer passed-in memory when possible. The type of the
buffer in the property_addr_info is changed to an array_view so that
bounds checking can be done.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_discrete_type_high_bound, ada_discrete_type_low)
(ada_value_primitive_packed_val): Update.
* ada-valprint.c (ada_value_print_1): Update.
* dwarf2/loc.c (evaluate_for_locexpr_baton): New struct.
(dwarf2_locexpr_baton_eval): Take a property_addr_info rather than
just an address. Use evaluate_for_locexpr_baton.
(dwarf2_evaluate_property): Update.
* dwarf2/loc.h (struct property_addr_info) <valaddr>: Now an
array_view.
* findvar.c (default_read_var_value): Update.
* gdbtypes.c (compute_variant_fields_inner)
(resolve_dynamic_type_internal): Update.
(resolve_dynamic_type): Change type of valaddr parameter.
* gdbtypes.h (resolve_dynamic_type): Update.
* valarith.c (value_subscripted_rvalue): Update.
* value.c (value_from_contents_and_address): Update.
Tom Tromey
Hannes Domani
Andrew Burgess
Philippe Waroquiers
Kamil Rytarowski
Tom de Vries
Simon Marchi
Sterling Augustine
Tom Tromey
Luis Machado