| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Replace all uses of it by type::field.
Note that since type::field returns a reference to the field, some spots
are used to assign the whole field structure. See ctfread.c, function
attach_fields_to_type, for example. This is the same as was happening
with the macro, so I don't think it's a problem, but if anybody sees a
really nicer way to do this, now could be a good time to implement it.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD): Remove. Replace all uses with
type::field.
|
|
Remove all uses of the `TYPE_FIELDS` macro. Replace them with either:
1) type::fields, to obtain a pointer to the fields array (same as
TYPE_FIELDS yields)
2) type::field, a new convenience method that obtains a reference to one
of the type's field by index. It is meant to replace
TYPE_FIELDS (type)[idx]
with
type->field (idx)
gdb/ChangeLog:
* gdbtypes.h (struct type) <field>: New method.
(TYPE_FIELDS): Remove, replace all uses with either type::fields
or type::field.
Change-Id: I49fba10114417deb502060c6156aa5f7fc62462f
|
|
Add the `fields` and `set_fields` methods on `struct type`, in order to
remove the `TYPE_FIELDS` macro. In this patch, the `TYPE_FIELDS` macro
is changed to the `type::fields`, so all the call sites that use it to
set the fields array are changed to use `type::set_fields`. The next
patch will remove `TYPE_FIELDS` entirely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <fields, set_fields>: New methods.
(TYPE_FIELDS): Use type::fields. Change all call sites that
modify the propery to use type::set_fields instead.
Change-Id: I05174ce68f2ce3fccdf5d8b469ff141f14886b33
|
|
Remove `TYPE_NFIELDS`, changing all the call sites to use
`type::num_fields` directly. This is quite a big diff, but this was
mostly done using sed and coccinelle. A few call sites were done by
hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NFIELDS): Remove. Change all cal sites to use
type::num_fields instead.
Change-Id: Ib73be4c36f9e770e0f729bac3b5257d7cb2f9591
|
|
Add the `num_fields` and `set_num_fields` methods on `struct type`, in
order to remove the `TYPE_NFIELDS` macro. In this patch, the
`TYPE_NFIELDS` macro is changed to use `type::num_fields`, so all the
call sites that are used to set the number of fields are changed to use
`type::set_num_fields`. The next patch will remove `TYPE_NFIELDS`
completely.
I think that in the future, we should consider making the interface of
`struct type` better. For example, right now it's possible for the
number of fields property and the actual number of fields set to be out
of sync. However, I want to keep the existing behavior in this patch,
just translate from macros to methods.
gdb/ChangeLog:
* gdbtypes.h (struct type) <num_fields, set_num_fields>: New
methods.
(TYPE_NFIELDS): Use type::num_fields. Change all call sites
that modify the number of fields to use type::set_num_fields
instead.
Change-Id: I5ad9de5be4097feaf942d111077434bf91d13dc5
|
|
When running test-case gdb.base/with.exp with target board cc-with-gdb-index,
we have:
...
(gdb) PASS: gdb.base/with.exp: basics: show language
with language ada -- print g_s^M
'g_s' has unknown type; cast it to its declared type^M
(gdb) FAIL: gdb.base/with.exp: basics: with language ada -- print g_s
...
This is due to this bit in dw2_map_matching_symbols:
...
if (dwarf2_per_objfile->index_table != nullptr)
{
/* Ada currently doesn't support .gdb_index (see PR24713). We can get
here though if the current language is Ada for a non-Ada objfile
using GNU index. As Ada does not look for non-Ada symbols this
function should just return. */
return;
}
...
While the reasoning in the comment may be sound from language perspective, it
does introduce an inconsistency in gdb behaviour between:
- having a .gdb_index section, and
- having a .gdb_names section, or a partial symtab, or -readnow.
Fix the inconsistency by completing implementation of
dw2_map_matching_symbols.
Tested on x86_64-linux, both with native and target board
cc-with-debug-index.
gdb/ChangeLog:
2020-05-20 Tom de Vries <tdevries@suse.de>
PR symtab/25833
* dwarf2/read.c (dw2_map_matching_symbols): Handle .gdb_index.
gdb/testsuite/ChangeLog:
2020-05-20 Tom de Vries <tdevries@suse.de>
PR symtab/25833
* gdb.base/with-mf-inc.c: New test.
* gdb.base/with-mf-main.c: New test.
* gdb.base/with-mf.exp: New file.
|
|
This patch makes gdb use the inline accessor for all bfd->filename
read accesses.
* coff-pe-read.c (read_pe_exported_syms): Use bfd_get_filename
rather than accessing bfd->filename directly.
* dtrace-probe.c (dtrace_static_probe_ops::get_probes): Likewise,
and use bfd_section_name.
* dwarf2/frame.c (decode_frame_entry): Likewise.
* exec.c (exec_set_section_address): Likewise.
* solib-aix.c (solib_aix_bfd_open): Likewise.
* stap-probe.c (get_stap_base_address): Likewise.
* symfile.c (reread_symbols): Likewise.
|
|
Found by inspection, so I don't have a test for it (I don't think it
would be easy to have this bug cause a failure reliably).
We allocate space for N fields into `new_fields`, then memcpy N fields
at `new_fields + 1`. This overflows the allocated buffer by one field.
Fix it by allocating `N + 1` fields.
gdb/ChangeLog:
* dwarf2/read.c (quirk_rust_enum): Allocate enough fields.
|
|
A following patch will add one more defaulted parameter.
gdb/ChangeLog:
2020-05-19 Pedro Alves <palves@redhat.com>
* gdb_bfd.h: (gdb_bfd_open): Default to 'fd' parameter to -1.
Adjust all callers.
|
|
Remove `TYPE_NAME`, changing all the call sites to use `type::name`
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NAME): Remove. Change all cal sites to use
type::name instead.
|
|
Add the `name` and `set_name` methods on `struct type`, in order to
remove the `TYPE_NAME` macro. In this patch, the `TYPE_NAME` macro is
changed to use `type::name`, so all the call sites that are used to set
the type name are changed to use `type::set_name`. The next patch will
remove `TYPE_NAME` completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <name, set_name>: New methods.
(TYPE_CODE): Use type::name. Change all call sites used to set
the name to use type::set_name instead.
|
|
This removes allocate_symbol, allocate_template_symbol, and
initialize_objfile_symbol in favor of changing the default values for
symbol members, and updating the one per-arch caller.
gdb/ChangeLog
2020-05-15 Tom Tromey <tom@tromey.com>
* language.c (language_alloc_type_symbol): Set
SYMBOL_SECTION.
* symtab.c (initialize_objfile_symbol): Remove.
(allocate_symbol): Remove.
(allocate_template_symbol): Remove.
* dwarf2/read.c (fixup_go_packaging): Use "new".
(new_symbol): Use "new".
(read_variable): Don't call initialize_objfile_symbol. Use
"new".
(read_func_scope): Use "new".
* xcoffread.c (process_xcoff_symbol): Don't call
initialize_objfile_symbol.
(SYMBOL_DUP): Remove.
* coffread.c (process_coff_symbol, coff_read_enum_type): Use
"new".
* symtab.h (allocate_symbol, initialize_objfile_symbol)
(allocate_template_symbol): Don't declare.
(struct symbol): Add copy constructor. Change defaults.
* jit.c (finalize_symtab): Use "new".
* ctfread.c (ctf_add_enum_member_cb, new_symbol, ctf_add_var_cb):
Use "new".
* stabsread.c (patch_block_stabs, define_symbol, read_enum_type)
(common_block_end): Use "new".
* mdebugread.c (parse_symbol): Use "new".
(new_symbol): Likewise.
|
|
cmd_show_list function implements the 'show' command.
cmd_show_list output is inconsistent: it sometimes shows a prefix
and sometimes does not.
For example, in the below, you see that there is a prefix before
each value, except for 'enabled'.
(gdb) show style
style address background: The "address" style background color is: none
style address foreground: The "address" style foreground color is: blue
style address intensity: The "address" style display intensity is: normal
enabled: CLI output styling is enabled.
style filename background: The "filename" style background color is: none
...
There are other inconsistencies or bugs e.g. in
the below we see twice insn-number-max, once with a prefix
and once without prefix : last line, just before the value of
instruction-history-size which is itself without prefix.
(gdb) show record
record btrace bts buffer-size: The record/replay bts buffer size is 65536.
record btrace cpu: btrace cpu is 'auto'.
record btrace pt buffer-size: The record/replay pt buffer size is 16384.
record btrace replay-memory-access: Replay memory access is read-only.
record full insn-number-max: Record/replay buffer limit is 200000.
record full memory-query: Whether query if PREC cannot record memory change of next instruction is off.
record full stop-at-limit: Whether record/replay stops when record/replay buffer becomes full is on.
function-call-history-size: Number of functions to print in "record function-call-history" is 10.
insn-number-max: instruction-history-size: Number of instructions to print in "record instruction-history" is 10.
(gdb)
Also, some values are output several times due to some aliases, so avoid outputting duplicated
values by skipping all aliases.
Now that the command structure has a correct 'back-pointer' from a command
to its prefix command, we can simplify cmd_show_list by removing its prefix argument
and at the same time fix the output inconsistencies and bugs.
gdb/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-setshow.h (cmd_show_list): Remove prefix argument.
* cli/cli-decode.c (do_show_prefix_cmd): Likewise.
* command.h (cmd_show_list): Likewise.
* dwarf2/index-cache.c (show_index_cache_command): Likewise.
* cli/cli-setshow.c (cmd_show_list): Use the prefix to produce the output. Skip aliases.
gdb/testsuite/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/default.exp: Update output following fixes.
|
|
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
|
|
Add the code and set_code methods on code, in order to remove the
TYPE_CODE macro. In this patch, the TYPE_CODE macro is changed to use
type::code, so all the call sites that are used to set the type code are
changed to use type::set_code. The next patch will remove TYPE_CODE
completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <code, set_code>: New methods.
(TYPE_CODE): Use type::code. Change all call sites used to set
the code to use type::set_code instead.
|
|
When running test-case gdb.fortran/info-modules.exp with target board
debug-names, I run into:
...
FAIL: gdb.fortran/info-modules.exp: info modules: check for entry \
'info-types-2.f90', '18', 'mod2'
...
In more detail, comparing the behaviour of the executable without and with
.debug_names section, we have:
...
-$ gdb -batch info-modules -ex "info modules"
+$ gdb -batch info-modules.debugnames -ex "info modules"
All defined modules:
-File /data/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types-2.f90:
-18: mod2
-
File /data/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types.f90:
16: mod1
...
This is due to the fact that the .debug_names section does not contain
DW_TAG_module entries.
Fix this in debug_names::psymbol_tag.
Build and tested on x86_64-linux with target board debug-names.
gdb/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
* dwarf2/index-write.c (debug_names::psymbol_tag): Handle
MODULE_DOMAIN.
|
|
Consider the following two-file test-case:
...
$ cat main.c
extern int foo (void);
int
main (void)
{
int sum, a, b;
sum = a + b + foo ();
return sum;
}
$ cat foo.c
int
foo (void)
{
return 3;
}
...
Compiled like this:
...
$ clang-10 -gdwarf-5 -gpubnames -c main.c
$ clang-10 -gdwarf-5 -c foo.c
$ clang-10 -gdwarf-5 -gpubnames main.o foo.o
...
When loading this exec into gdb, we run into this assert:
...
$ gdb a.out
Reading symbols from a.out...
warning: Section .debug_aranges in a.out entry at offset 0 \
debug_info_offset 0 does not exists, ignoring .debug_aranges.
src/gdb/dwarf2/read.c:6949: \
internal-error: cutu_reader::cutu_reader(dwarf2_per_cu_data*, \
abbrev_table*, int, bool): \
Assertion `this_cu->length == cu->header.get_length ()' failed.
...
The problem is that the determined length of the CU:
...
(gdb) p /x this_cu->length
$4 = 0x26a
...
does not match the actual length:
...
(gdb) p /x cu->header.get_length ()
$5 = 0x59
...
The length of the CU is determined in create_cus_from_debug_names_list, and
set based on this list in the .debug_names section:
...
Compilation Unit offsets [
CU[0]: 0x000000c7
]
...
and it is assumed that this is a complete list, so the size of the CU is
calculated using the end of the .debug_section at 0x331, making it 0x331 -
0xc7 == 0x26a.
However, the CU list is not complete:
...
$ llvm-dwarfdump -debug-info a.out \
| grep "Compile Unit" \
| sed 's/Compile Unit.*//'
0x00000000:
0x0000002e:
0x000000a5:
0x000000c7:
0x00000120:
0x00000157:
0x0000030f:
...
In particular, because the CU for foo.c is there at 0x120 (the rest of the CUs
is due to openSUSE having debug info for various linked in objects).
Fix the assert by not assuming to know the length of CUs in
create_cus_from_debug_names_list (if the .debug_names is not produced by GDB),
and setting it to 0, and setting it later to the actual length.
Note that this does not fix the .debug_aranges warning, that's PR25969.
Build and tested on x86_64-linux, with native and debug-names.
gdb/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
PR symtab/25941
* dwarf2/read.c (create_cus_from_debug_names_list): Initialize CUs
with length 0, if not gdb-produced.
(cutu_reader::cutu_reader): Set CU length to actual length if 0.
gdb/testsuite/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
PR symtab/25941
* gdb.dwarf2/clang-debug-names.exp.in: New include exp file, factored
out of ...
* gdb.dwarf2/clang-debug-names.exp: ... here.
* gdb.dwarf2/clang-debug-names-2.exp: New file. Include
clang-debug-names.exp.in.
* gdb.dwarf2/clang-debug-names-2-foo.c: New test.
* gdb.dwarf2/clang-debug-names-2.c: New test.
|
|
.debug_names form
Following complaint is observed with the executable compiled with -gdwarf-5
and -gpubnames flags - "During symbol reading: Unsupported .debug_names form
DW_FORM_ref4". This is the form corresponding to DW_IDX_die_offset attribute.
This patch fixes this complaint. Tested with clang 10.0.0. Test case used -
int main()
{
int sum,a,b;
sum = a + b;
return sum;
}
clang -gdwarf-5 -gpubnames test.c -o test.out
gdb -q test.out -ex "set complaints 1" -ex "start"
Reading symbols from test.out...
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
Temporary breakpoint 1 at 0x400484
Starting program: test.out
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
gdb/dwarf2/ChangeLog:
2020-05-09 Nitika Achra <Nitika.Achra@amd.com>
PR symtab/25952
* read.c (dw2_debug_names_iterator::next): Handle DW_FORM_ref*
and DW_IDX_die_offset. If there is no compilation unit attribute in
the index entry, then there is a single CU. Return the CU at O index
of compilation unit vector.
gdb/testsuite/ChangeLog:
2020-05-09 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/clang-debug-names.exp: Remove PR25952 kfail.
|
|
A customer reported a crash in the DWARF reader.
Investigation showed that the crash occurred in an unusual scenario: a
function was lexically scoped within some other function -- but the
inner function inlined the outer function and referred to its DIE via
DW_AT_abstract_origin. With the executable in question,
inherit_abstract_dies could eventually call read_lexical_block_scope,
which in turn could recurse into process_die, to process a DIE that
was already being read, triggering an assert.
This came up once before; see:
https://www.sourceware.org/ml/gdb-patches/2014-02/msg00652.html
However, in this case, I don't have an easy way to reproduce. So,
there is no test case.
I did experiment with the failing executable. This patch fixes the
bug and doesn't seem to cause other issues. For example, I can still
set breakpoints on the relevant functions.
gdb/ChangeLog
2020-05-08 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_lexical_block_scope): Don't process a DIE
already being processed.
|
|
I noticed that cp_canonicalize_string and friends copy a
unique_xmalloc_ptr to a std::string. However, this copy isn't
genuinely needed anywhere, and it serves to slow down DWARF psymbol
reading.
This patch removes the copy and updates the callers to adapt.
This speeds up the reader from 1.906 seconds (mean of 10 runs, of gdb
on a copy of itself) to 1.888 seconds (mean of 10 runs, on the same
copy as the first trial).
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
* symtab.h (class demangle_result_storage) <set_malloc_ptr>: New
overload.
<swap_string, m_string>: Remove.
* symtab.c (demangle_for_lookup, completion_list_add_symbol):
Update.
* stabsread.c (define_symbol, read_type): Update.
* linespec.c (find_linespec_symbols): Update.
* gnu-v3-abi.c (gnuv3_get_typeid): Update.
* dwarf2/read.c (dwarf2_canonicalize_name): Update.
* dbxread.c (read_dbx_symtab): Update.
* cp-support.h (cp_canonicalize_string_full)
(cp_canonicalize_string, cp_canonicalize_string_no_typedefs):
Return unique_xmalloc_ptr.
* cp-support.c (inspect_type): Update.
(cp_canonicalize_string_full): Return unique_xmalloc_ptr.
(cp_canonicalize_string_no_typedefs, cp_canonicalize_string):
Likewise.
* c-typeprint.c (print_name_maybe_canonical): Update.
* break-catch-throw.c (check_status_exception_catchpoint):
Update.
|
|
Move add_dyn_prop, currently a free function, to be a method of struct
type.
gdb/ChangeLog:
* gdbtypes.h (struct type) <add_dyn_prop>: New method.
(add_dyn_prop): Remove. Update all users to use
type::add_dyn_prop.
* gdbtypes.c (add_dyn_prop): Rename to...
(type::add_dyn_prop): ... this.
|
|
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.
|
|
This reverts commit 84ed7a472551bce1ac58e0eced619433fabc956c.
The problem that the commit attempts to address has already been fixed in
commit 770479f223e "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).
|
|
* dwarf2/read.c (setup_type_unit_groups): Set list_in_scope.
|
|
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.
|
|
When debugging a program compiled with -fdebug-types-section,
only the first top-level type in each file is visible to gdb.
The problem was caused by moving the assignment to list_in_scope
from process_full_comp_unit and process_full_type_unit to
start_symtab. This was fine for process_full_comp_unit, because
symtabs and comp units are one-to-one. But there can be many type
units per symtab (one for each type), and we only call start_symtab
for the first one. This adds the necessary assignments on the paths
where start_symtab is not called.
gdb/Changelog:
2020-04-28 Mark Williams <mark@myosotissp.com>
PR gdb/24480
* dwarf2read.c: Add missing assingments to list_in_scope when
start_symtab was already called.
gdb/testsuite/Changelog:
2020-04-28 Mark Williams <mark@myosotissp.com>
PR gdb/24480
* dw4-toplevel-types.exp: Test for top level types.
* dw4-toplevel-types.cc: Test for top level types.
|
|
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 f23f598e28ad ("[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.
|
|
Commit 5939967b355ba6a940887d19847b7893a4506067 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 5939967b355ba6a940887d19847b7893a4506067), 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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Some DWARF expressions must be evaluated by first pushing the object
address onto the evaluation stack. This patch adds this ability.
This functionality is not used yet, but it will be used in a later
patch. This is split out for easier review and also because it
improved the patch series ordering.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add
"push_initial_value" parameter.
(dwarf2_evaluate_property): Likewise.
* dwarf2/loc.h (dwarf2_evaluate_property): Update.
|
|
There has been some breakage for aarch64-linux, arm-linux and s390-linux in
terms of inline frame unwinding. There may be other targets, but these are
the ones i'm aware of.
The following testcases started to show numerous failures and trigger internal
errors in GDB after commit 1009d92fc621bc4d017029b90a5bfab16e17fde5,
"Find tailcall frames before inline frames".
gdb.opt/inline-break.exp
gdb.opt/inline-cmds.exp
gdb.python/py-frame-inline.exp
gdb.reverse/insn-reverse.exp
The internal errors were of this kind:
binutils-gdb/gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.
After a lengthy investigation to try and find the cause of these assertions,
it seems we're dealing with some fragile/poorly documented code to handle inline
frames and we are attempting to unwind from this fragile section of code.
Before commit 1009d92fc621bc4d017029b90a5bfab16e17fde5, the tailcall sniffer
was invoked from dwarf2_frame_prev_register. By the time we invoke the
dwarf2_frame_prev_register function, we've probably already calculated the
frame id (via compute_frame_id).
After said commit, the call to dwarf2_tailcall_sniffer_first was moved to
dwarf2_frame_cache. This is very early in a frame creation process, and
we're still calculating the frame ID (so compute_frame_id is in the call
stack).
This would be fine for regular frames, but the above testcases all deal
with some inline frames.
The particularity of inline frames is that their frame ID's depend on
the previous frame's ID, and the previous frame's ID relies in the inline
frame's registers. So it is a bit of a messy situation.
We have comments in various parts of the code warning about some of these
particularities.
In the case of dwarf2_tailcall_sniffer_first, we attempt to unwind the PC,
which goes through various functions until we eventually invoke
frame_unwind_got_register. This function will eventually attempt to create
a lazy value for a particular register, and this lazy value will require
a valid frame ID. Since the inline frame doesn't have a valid frame ID
yet (remember we're still calculating the previous frame's ID so we can tell
what the inline frame ID is) we will call compute_frame_id for the inline
frame (level 0).
We'll eventually hit the assertion above, inside get_frame_id:
--
/* If we haven't computed the frame id yet, then it must be that
this is the current frame. Compute it now, and stash the
result. The IDs of other frames are computed as soon as
they're created, in order to detect cycles. See
get_prev_frame_if_no_cycle. */
gdb_assert (fi->level == 0);
--
It seems to me we shouldn't have reached this assertion without having the
inline frame ID already calculated. In fact, it seems we even start recursing
a bit when we invoke get_prev_frame_always within inline_frame_this_id. But
a check makes us quit the recursion and proceed to compute the id.
Here's the call stack for context:
#0 get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2109
RECURSION - #1 0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124
#2 0x0000aaaaaae95768 in inline_frame_this_id (this_frame=0xaaaaab85a670, this_cache=0xaaaaab85a688, this_id=0xaaaaab85a6d0)
at ../../../repos/binutils-gdb/gdb/inline-frame.c:165
#3 0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:550
#4 0x0000aaaaaae19318 in get_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:582
#5 0x0000aaaaaae13480 in value_of_register_lazy (frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/findvar.c:296
#6 0x0000aaaaaae16c00 in frame_unwind_got_register (frame=0xaaaaab85a730, regnum=30, new_regnum=30) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:268
#7 0x0000aaaaaad52604 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=30)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1296
#8 0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1229
#9 0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1320
#10 0x0000aaaaaab76574 in aarch64_dwarf2_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32)
at ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:1114
#11 0x0000aaaaaad52724 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1316
#12 0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1229
#13 0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1320
#14 0x0000aaaaaae16a84 in default_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:223
#15 0x0000aaaaaae32124 in gdbarch_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/gdbarch.c:3074
#16 0x0000aaaaaad4f15c in dwarf2_tailcall_sniffer_first (this_frame=0xaaaaab85a730, tailcall_cachep=0xaaaaab85a830, entry_cfa_sp_offsetp=0x0)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame-tailcall.c:388
#17 0x0000aaaaaad520c0 in dwarf2_frame_cache (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748) at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1190
#18 0x0000aaaaaad52204 in dwarf2_frame_this_id (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, this_id=0xaaaaab85a790)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1218
#19 0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame.c:550
#20 0x0000aaaaaae1c958 in get_prev_frame_if_no_cycle (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:1927
#21 0x0000aaaaaae1cc44 in get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2006
FIRST CALL - #22 0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124
#23 0x0000aaaaaae18f68 in skip_artificial_frames (frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:495
#24 0x0000aaaaaae193e8 in get_stack_frame_id (next_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:596
#25 0x0000aaaaaae87a54 in process_event_stop_test (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6857
#26 0x0000aaaaaae86bdc in handle_signal_stop (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6381
#27 0x0000aaaaaae84fd0 in handle_inferior_event (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:5578
#28 0x0000aaaaaae81588 in fetch_inferior_event (client_data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:4020
#29 0x0000aaaaaae5f7fc in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at ../../../repos/binutils-gdb/gdb/inf-loop.c:43
#30 0x0000aaaaaae8d768 in infrun_async_inferior_event_handler (data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:9377
#31 0x0000aaaaaabff970 in check_async_event_handlers () at ../../../repos/binutils-gdb/gdb/async-event.c:291
#32 0x0000aaaaab27cbec in gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:194
#33 0x0000aaaaaaef1894 in start_event_loop () at ../../../repos/binutils-gdb/gdb/main.c:356
#34 0x0000aaaaaaef1a04 in captured_command_loop () at ../../../repos/binutils-gdb/gdb/main.c:416
#35 0x0000aaaaaaef3338 in captured_main (data=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1254
#36 0x0000aaaaaaef33a0 in gdb_main (args=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1269
#37 0x0000aaaaaab6e0dc in main (argc=6, argv=0xfffffffff348) at ../../../repos/binutils-gdb/gdb/gdb.c:32
The following patch addresses this by using a function that unwinds the PC
from the next (inline) frame directly as opposed to creating a lazy value
that is bound to the next frame's ID (still not computed).
gdb/ChangeLog:
2020-04-23 Luis Machado <luis.machado@linaro.org>
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Use
get_frame_register instead of gdbarch_unwind_pc.
|
|
PR ada/25837 points out a crash in the gdb testsuite when .debug_names
is used. You can reproduce like:
runtest --target_board=cc-with-debug-names \
gdb.ada/big_packed_array.exp
The bug was introduced by commit e0802d599 ("Avoid copying in
lookup_name_info"). The problem is that the return type of
language_lookup_name changed, but in a way that didn't cause existing
callers to trigger a compilation error. Previously, it returned a
"const string &", but after it returned a "const char *". This caused
a string to be created in dw2_expand_symtabs_matching_symbol, but one
that had too short of a lifetime; so eventually the matcher cache
would wind up with invalid data.
This patch fixes the problem by updating the callers to use the new
type.
Tested on x86-64 Fedora 30.
gdb/ChangeLog
2020-04-23 Tom Tromey <tromey@adacore.com>
PR ada/25837:
* dwarf2/read.c (dw2_expand_symtabs_matching_symbol): Store a
"const char *", not a "const std::string &".
<name_and_matcher::operator==>: Update.
* unittests/lookup_name_info-selftests.c: Change type of
"result".
|
|
Consider a test-case consisting of source file test.c:
...
extern int aaa;
int
main (void)
{
return 0;
}
...
and test-2.c:
...
int aaa = 33;
...
compiled with debug info only for test.c:
...
$ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g
...
When trying to print aaa, we get:
...
$ gdb -batch a.out -ex "print aaa"
'aaa' has unknown type; cast it to its declared type
...
but with -readnow we have:
...
$ gdb -readnow -batch a.out -ex "print aaa"
$1 = 33
...
In the -readnow case, the symbol for aaa in the full symtab has
LOC_UNRESOLVED, and the symbol type is combined with the minimal symbol
address, to read the value and print it without cast.
Without the -readnow, we create partial symbols, but the aaa decl is missing
from the partial symtabs, so we find it only in the minimal symbols, resulting
in the cast request. If the aaa decl would have been in the partial symtabs,
it would have been found, and the full symtab would have been expanded, after
which things would be as with -readnow.
The function add_partial_symbol has a comment on the LOC_UNRESOLVED +
minimal symbol addres construct at DW_TAG_variable handling:
...
else if (pdi->is_external)
{
/* Global Variable.
Don't enter into the minimal symbol tables as there is
a minimal symbol table entry from the ELF symbols already.
Enter into partial symbol table if it has a location
descriptor or a type.
If the location descriptor is missing, new_symbol will create
a LOC_UNRESOLVED symbol, the address of the variable will then
be determined from the minimal symbol table whenever the variable
is referenced.
...
but it's not triggered due to this test in scan_partial_symbols:
...
case DW_TAG_variable:
...
if (!pdi->is_declaration)
{
add_partial_symbol (pdi, cu);
}
...
Fix this in scan_partial_symbols by allowing external variable decls to be
added to the partial symtabs.
Build and reg-tested on x86_64-linux.
The patch caused this regression:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while without the patch we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...
However, without the patch but with -readnow we have the same FAIL as with the
patch (filed as PR25807). In other words, the patch has the effect that we
get the same result with and without -readnow.
This can be explained as follows. Without the patch, and without -readnow, we
have two a_thread_locals, the def and the decl:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot read `a_thread_local' without registers
int a_thread_local; computed at runtime
int a_thread_local; unresolved
...
while without the patch and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
int a_thread_local; unresolved
int a_thread_local; computed at runtime
...
With the patch we have the same order with and without -readnow, but just a
different one than before without -readnow.
Mark the "Cannot find thread-local variables on this target" variant a PR25807
kfail.
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* dwarf2/read.c (scan_partial_symbols): Allow external variable decls
in psymtabs.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* gdb.base/psym-external-decl-2.c: New test.
* gdb.base/psym-external-decl.c: New test.
* gdb.base/psym-external-decl.exp: New file.
* gdb.threads/tls.exp: Add PR25807 kfail.
|
|
Consider the executable generated for test-case gdb.dwarf2/imported-unit.exp.
When loading the executable using various tracing:
...
$ gdb \
outputs/gdb.dwarf2/imported-unit/imported-unit \
-batch \
-iex "set verbose on" \
-iex "set debug symtab-create 1"
...
Created psymtab 0x213f380 for module <artificial>@0xc7.
Created psymtab 0x20e7b00 for module imported_unit.c.
Created psymtab 0x215da20 for module imported_unit.c.
Created psymtab 0x2133630 for module elf-init.c.
Created psymtab 0x215b910 for module ../sysdeps/x86_64/crtn.S.
...
we notice that there are two psymtabs generated for imported_unit.c.
This is due to the following: in dwarf2_build_psymtabs_hard we loop over CUs
and generate partial symtabs for those, and if we encounter an import of
another CU, we also generate a partial symtab for that one, unless already
created.
This works well with backward import references:
- the imported CU is read
- then the importing CU is read
- the import is encountered, but the imported CU is already read, so
we're done.
But with forward import references, we have instead:
- the importing CU is read
- the import is encountered, and the imported CU is read
- the imported CU is read once more
Fix this by skipping already created psymtabs in the loop in
dwarf2_build_psymtabs_hard.
Tested on x86_64-linux, with native and target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects.
This causes this regression with the target board:
...
FAIL: gdb.ada/dgopt.exp: list x.adb:16, 16
...
which I consider a seperate PR, filed as PR25801 - "Filename of shared psymtab
is ignored".
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25700
* dwarf2/read.c (dwarf2_build_psymtabs_hard): Don't create psymtab for
CU if already created.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25700
* gdb.dwarf2/imported-unit.exp: Verify that there's only one partial
symtab for imported_unit.c.
|
|
This changes get_objfile_arch to be a new inline method,
objfile::arch.
To my surprise, this function came up while profiling DWARF psymbol
reading. Making this change improved performance from 1.986 seconds
to 1.869 seconds. Both measurements were done by taking the mean of
10 runs on a fixed copy of the gdb executable.
gdb/ChangeLog
2020-04-18 Tom Tromey <tom@tromey.com>
* xcoffread.c (enter_line_range, scan_xcoff_symtab): Update.
* value.c (value_fn_field): Update.
* valops.c (find_function_in_inferior)
(value_allocate_space_in_inferior): Update.
* tui/tui-winsource.c (tui_update_source_windows_with_line):
Update.
* tui/tui-source.c (tui_source_window::set_contents): Update.
* symtab.c (lookup_global_or_static_symbol)
(find_function_start_sal_1, skip_prologue_sal)
(print_msymbol_info, find_gnu_ifunc, symbol_arch): Update.
* symmisc.c (dump_msymbols, dump_symtab_1)
(maintenance_print_one_line_table): Update.
* symfile.c (init_entry_point_info, section_is_mapped)
(list_overlays_command, simple_read_overlay_table)
(simple_overlay_update_1): Update.
* stap-probe.c (handle_stap_probe): Update.
* stabsread.c (dbx_init_float_type, define_symbol)
(read_one_struct_field, read_enum_type, read_range_type): Update.
* source.c (info_line_command): Update.
* python/python.c (gdbpy_source_objfile_script)
(gdbpy_execute_objfile_script): Update.
* python/py-type.c (save_objfile_types): Update.
* python/py-objfile.c (py_free_objfile): Update.
* python/py-inferior.c (python_new_objfile): Update.
* psymtab.c (psym_find_pc_sect_compunit_symtab, dump_psymtab)
(dump_psymtab_addrmap_1, maintenance_info_psymtabs)
(maintenance_check_psymtabs): Update.
* printcmd.c (info_address_command): Update.
* objfiles.h (struct objfile) <arch>: New method, from
get_objfile_arch.
(get_objfile_arch): Don't declare.
* objfiles.c (get_objfile_arch): Remove.
(filter_overlapping_sections): Update.
* minsyms.c (msymbol_is_function): Update.
* mi/mi-symbol-cmds.c (mi_cmd_symbol_list_lines)
(output_nondebug_symbol): Update.
* mdebugread.c (parse_symbol, basic_type, parse_partial_symbols)
(mdebug_expand_psymtab): Update.
* machoread.c (macho_add_oso_symfile): Update.
* linux-tdep.c (linux_infcall_mmap, linux_infcall_munmap):
Update.
* linux-fork.c (checkpoint_command): Update.
* linespec.c (convert_linespec_to_sals): Update.
* jit.c (finalize_symtab): Update.
* infrun.c (insert_exception_resume_from_probe): Update.
* ia64-tdep.c (ia64_find_unwind_table): Update.
* hppa-tdep.c (internalize_unwinds): Update.
* gdbtypes.c (get_type_arch, init_float_type, objfile_type):
Update.
* gcore.c (call_target_sbrk): Update.
* elfread.c (record_minimal_symbol, elf_symtab_read)
(elf_rel_plt_read, elf_gnu_ifunc_record_cache)
(elf_gnu_ifunc_resolve_by_got): Update.
* dwarf2/read.c (create_addrmap_from_index)
(create_addrmap_from_aranges, dw2_find_pc_sect_compunit_symtab)
(read_debug_names_from_section)
(process_psymtab_comp_unit_reader, add_partial_symbol)
(add_partial_subprogram, process_full_comp_unit)
(read_file_scope, read_func_scope, read_lexical_block_scope)
(read_call_site_scope, dwarf2_ranges_read)
(dwarf2_record_block_ranges, dwarf2_add_field)
(mark_common_block_symbol_computed, read_tag_pointer_type)
(read_tag_string_type, dwarf2_init_float_type)
(dwarf2_init_complex_target_type, read_base_type)
(partial_die_info::read, partial_die_info::read)
(read_attribute_value, dwarf_decode_lines_1, new_symbol)
(dwarf2_fetch_die_loc_sect_off): Update.
* dwarf2/loc.c (dwarf2_find_location_expression)
(class dwarf_evaluate_loc_desc, rw_pieced_value)
(dwarf2_evaluate_loc_desc_full, dwarf2_locexpr_baton_eval)
(dwarf2_loc_desc_get_symbol_read_needs)
(locexpr_describe_location_piece, locexpr_describe_location_1)
(loclist_describe_location): Update.
* dwarf2/index-write.c (write_debug_names): Update.
* dwarf2/frame.c (dwarf2_build_frame_info): Update.
* dtrace-probe.c (dtrace_process_dof): Update.
* dbxread.c (read_dbx_symtab, dbx_end_psymtab)
(process_one_symbol): Update.
* ctfread.c (ctf_init_float_type, read_base_type): Update.
* coffread.c (coff_symtab_read, enter_linenos, decode_base_type)
(coff_read_enum_type): Update.
* cli/cli-cmds.c (edit_command, list_command): Update.
* buildsym.c (buildsym_compunit::finish_block_internal): Update.
* breakpoint.c (create_overlay_event_breakpoint)
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, get_sal_arch): Update.
* block.c (block_gdbarch): Update.
* annotate.c (annotate_source_line): Update.
|
|
Currently there are many prefix commands that do nothing but call
either help_list or cmd_show_list. I happened to notice that one such
call, for "set print type", used the wrong command list parameter,
causing incorrect output.
Rather than fix this bug in isolation, I decided to eliminate this
possibility by adding two new ways to add prefix commands, which
simply route the call to help_list or cmd_show_list, as appropriate.
This makes it impossible for a mismatch to occur.
In some cases, a bit of output was removed; however, I don't think
this output in general was very useful. It seemed redundant with
what's already printed by help_list. A representative example is this
hunk, removed from ada-lang.c:
- printf_unfiltered (_(\
-"\"set ada\" must be followed by the name of a setting.\n"));
This simplified the CLI style set/show commands quite a bit, and
allowed the deletion of a macro.
This also cleans up some unusual code in windows-tdep.c.
Tested on x86-64 Fedora 30. Note that I have no way to build the
go32-nat.c change.
gdb/ChangeLog
2020-04-17 Tom Tromey <tromey@adacore.com>
* auto-load.c (show_auto_load_cmd): Remove.
(auto_load_show_cmdlist_get): Use add_show_prefix_cmd.
* arc-tdep.c (_initialize_arc_tdep): Use add_show_prefix_cmd.
(maintenance_print_arc_command): Remove.
* tui/tui-win.c (tui_command): Remove.
(tui_get_cmd_list): Use add_basic_prefix_cmd.
* tui/tui-layout.c (tui_layout_command): Remove.
(_initialize_tui_layout): Use add_basic_prefix_cmd.
* python/python.c (user_set_python, user_show_python): Remove.
(_initialize_python): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* guile/guile.c (set_guile_command, show_guile_command): Remove.
(install_gdb_commands): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(info_guile_command): Remove.
* dwarf2/read.c (set_dwarf_cmd, show_dwarf_cmd): Remove.
(_initialize_dwarf2_read): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cli/cli-style.h (class cli_style_option) <add_setshow_commands>:
Remove do_set and do_show parameters.
* cli/cli-style.c (set_style, show_style): Remove.
(_initialize_cli_style): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(cli_style_option::add_setshow_commands): Remove do_set and
do_show parameters.
(cli_style_option::add_setshow_commands): Use
add_basic_prefix_cmd, add_show_prefix_cmd.
(STYLE_ADD_SETSHOW_COMMANDS): Remove macro.
(set_style_name): Remove.
* cli/cli-dump.c (dump_command, append_command): Remove.
(srec_dump_command, ihex_dump_command, verilog_dump_command)
(tekhex_dump_command, binary_dump_command)
(binary_append_command): Remove.
(_initialize_cli_dump): Use add_basic_prefix_cmd.
* windows-tdep.c (w32_prefix_command_valid): Remove global.
(init_w32_command_list): Remove; move into ...
(_initialize_windows_tdep): ... here. Use add_basic_prefix_cmd.
* valprint.c (set_print, show_print, set_print_raw)
(show_print_raw): Remove.
(_initialize_valprint): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* typeprint.c (set_print_type, show_print_type): Remove.
(_initialize_typeprint): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* record.c (set_record_command, show_record_command): Remove.
(_initialize_record): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cli/cli-cmds.c (_initialize_cli_cmds): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(info_command, show_command, set_debug, show_debug): Remove.
* top.h (set_history, show_history): Don't declare.
* top.c (set_history, show_history): Remove.
* target-descriptions.c (set_tdesc_cmd, show_tdesc_cmd)
(unset_tdesc_cmd): Remove.
(_initialize_target_descriptions): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* symtab.c (info_module_command): Remove.
(_initialize_symtab): Use add_basic_prefix_cmd.
* symfile.c (overlay_command): Remove.
(_initialize_symfile): Use add_basic_prefix_cmd.
* sparc64-tdep.c (info_adi_command): Remove.
(_initialize_sparc64_adi_tdep): Use add_basic_prefix_cmd.
* sh-tdep.c (show_sh_command, set_sh_command): Remove.
(_initialize_sh_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* serial.c (serial_set_cmd, serial_show_cmd): Remove.
(_initialize_serial): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* ser-tcp.c (set_tcp_cmd, show_tcp_cmd): Remove.
(_initialize_ser_tcp): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* rs6000-tdep.c (set_powerpc_command, show_powerpc_command)
(_initialize_rs6000_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* riscv-tdep.c (show_riscv_command, set_riscv_command)
(show_debug_riscv_command, set_debug_riscv_command): Remove.
(_initialize_riscv_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* remote.c (remote_command, set_remote_cmd): Remove.
(_initialize_remote): Use add_basic_prefix_cmd.
* record-full.c (set_record_full_command)
(show_record_full_command): Remove.
(_initialize_record_full): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* record-btrace.c (cmd_set_record_btrace)
(cmd_show_record_btrace, cmd_set_record_btrace_bts)
(cmd_show_record_btrace_bts, cmd_set_record_btrace_pt)
(cmd_show_record_btrace_pt): Remove.
(_initialize_record_btrace): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* ravenscar-thread.c (set_ravenscar_command)
(show_ravenscar_command): Remove.
(_initialize_ravenscar): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* mips-tdep.c (show_mips_command, set_mips_command)
(_initialize_mips_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* maint.c (maintenance_command, maintenance_info_command)
(maintenance_check_command, maintenance_print_command)
(maintenance_set_cmd, maintenance_show_cmd): Remove.
(_initialize_maint_cmds): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(show_per_command_cmd): Remove.
* maint-test-settings.c (maintenance_set_test_settings_cmd):
Remove.
(maintenance_show_test_settings_cmd): Remove.
(_initialize_maint_test_settings): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* maint-test-options.c (maintenance_test_options_command):
Remove.
(_initialize_maint_test_options): Use add_basic_prefix_cmd.
* macrocmd.c (macro_command): Remove
(_initialize_macrocmd): Use add_basic_prefix_cmd.
* language.c (set_check, show_check): Remove.
(_initialize_language): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* infcmd.c (unset_command): Remove.
(_initialize_infcmd): Use add_basic_prefix_cmd.
* i386-tdep.c (set_mpx_cmd, show_mpx_cmd): Remove.
(_initialize_i386_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* go32-nat.c (go32_info_dos_command): Remove.
(_initialize_go32_nat): Use add_basic_prefix_cmd.
* cli/cli-decode.c (do_prefix_cmd, add_basic_prefix_cmd)
(do_show_prefix_cmd, add_show_prefix_cmd): New functions.
* frame.c (set_backtrace_cmd, show_backtrace_cmd): Remove.
(_initialize_frame): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* dcache.c (set_dcache_command, show_dcache_command): Remove.
(_initialize_dcache): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cp-support.c (maint_cplus_command): Remove.
(_initialize_cp_support): Use add_basic_prefix_cmd.
* btrace.c (maint_btrace_cmd, maint_btrace_set_cmd)
(maint_btrace_show_cmd, maint_btrace_pt_set_cmd)
(maint_btrace_pt_show_cmd, _initialize_btrace): Use
add_basic_prefix_cmd, add_show_prefix_cmd.
* breakpoint.c (save_command): Remove.
(_initialize_breakpoint): Use add_basic_prefix_cmd.
* arm-tdep.c (set_arm_command, show_arm_command): Remove.
(_initialize_arm_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* ada-lang.c (maint_set_ada_cmd, maint_show_ada_cmd)
(set_ada_command, show_ada_command): Remove.
(_initialize_ada_language): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* command.h (add_basic_prefix_cmd, add_show_prefix_cmd): Declare.
gdb/testsuite/ChangeLog
2020-04-17 Tom Tromey <tromey@adacore.com>
* gdb.cp/maint.exp (test_help): Simplify multiple_help_body.
Update tests.
* gdb.btrace/cpu.exp: Update tests.
* gdb.base/maint.exp: Update tests.
* gdb.base/default.exp: Update tests.
* gdb.base/completion.exp: Update tests.
|
|
Consider the test-case added in this patch, with resulting dwarf:
...
Compilation Unit @ offset 0xc7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x64
Pointer Size: 8
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<d3> DW_AT_language : 2 (non-ANSI C)
<d4> DW_AT_name : imported_unit.c
<1><e4>: Abbrev Number: 3 (DW_TAG_base_type)
<e5> DW_AT_byte_size : 4
<e6> DW_AT_encoding : 5 (signed)
<e7> DW_AT_name : int
<1><eb>: Abbrev Number: 4 (DW_TAG_subprogram)
<ec> DW_AT_name : main
<f1> DW_AT_type : <0xe4>
<f5> DW_AT_external : 1
<1><f6>: Abbrev Number: 0
Compilation Unit @ offset 0xf7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x85
Pointer Size: 8
<0><102>: Abbrev Number: 2 (DW_TAG_compile_unit)
<103> DW_AT_language : 2 (non-ANSI C)
<104> DW_AT_name : <artificial>
<1><111>: Abbrev Number: 3 (DW_TAG_subprogram)
<112> DW_AT_abstract_origin: <0xeb>
<116> DW_AT_low_pc : 0x4004a7
<11e> DW_AT_high_pc : 0x4004b2
<1><126>: Abbrev Number: 0
...
When run with target board cc-with-gdb-index, we run into:
...
(gdb) break main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1 at 0x4004ab
(gdb) PASS: gdb.dwarf2/imported-unit-runto-main.exp: setting breakpoint at main
run
Starting program: /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/imported-unit-runto-main/imported-unit-runto-main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1, warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
0x00000000004004ab in main ()
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
(gdb) FAIL: gdb.dwarf2/imported-unit-runto-main.exp: running to main in runto
...
Looking at the .gdb_index section contents using objdump --dwarf=gdb_index, we
have:
...
CU table:
[ 0] 0x0 - 0x2d
[ 1] 0x2e - 0xa4
[ 2] 0xa5 - 0xc6
[ 3] 0xf7 - 0x126
[ 4] 0x127 - 0x2de
[ 5] 0x2df - 0x300
Address table:
00000000004004a7 00000000004004b2 4
Symbol table:
[489] main: 4 [global, function]
...
We see that both the main symbol, and main address range map to CU 4, which has
offset range 0x127 - 0x2de, while main actually is contained in CU 3 at offset
range 0xf7 - 0x126.
This is caused by this continue in write_gdbindex, which triggers for the PU:
...
/* CU of a shared file from 'dwz -m' may be unused by this main file.
It may be referenced from a local scope but in such case it does not
need to be present in .gdb_index. */
if (psymtab == NULL)
continue;
...
The continue causes the PU to be skipped in the CU table (we can see that the
PU offset range 0xc7-0xf6 is missing) but the references are not taking that
into account.
I've tried fixing this in the optimal way, by updating the references, but ran
into trouble when follow_die_offset tries to find the CU for the inter-CU
ref. Because the PU is missing from the CU table,
dwarf2_find_containing_comp_unit bisects to the wrong CU.
Fix this by not skipping the PU in the CU table.
Build and reg-tested on x86_64-linux, with native and target boards
cc-with-gdb-index, cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* dwarf2/index-write.c (write_gdbindex): Generate CU table entries for
CUs without psymtab.
gdb/testsuite/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* gdb.dwarf2/gdb-add-index.exp (add_gdb_index): Move ...
(ensure_gdb_index): and factor out and move ...
* lib/gdb.exp (add_gdb_index, ensure_gdb_index): ... here.
* gdb.dwarf2/imported-unit-runto-main.exp: New file.
|
|
[ The test-case requires commit c1a66c0629 "[gdb] Expand symbolless symtabs
using maint expand-symtabs". ]
Consider the debug info for the test-case included in this patch. It consists
of a PU:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<1><d3>: Abbrev Number: 0
...
imported by a CU:
...
<0><df>: Abbrev Number: 2 (DW_TAG_compile_unit)
<e0> DW_AT_language : 2 (non-ANSI C)
<e1> DW_AT_stmt_list : 0xe9
<1><e5>: Abbrev Number: 3 (DW_TAG_imported_unit)
<e6> DW_AT_import : <0xd2> [Abbrev Number: 2]
<1><ea>: Abbrev Number: 0
...
and the CU has a dw2-symtab-includes.h file in the .debug_line file name
table:
...
The Directory Table (offset 0x101):
1 /data/gdb_versions/devel/src/gdb/testsuite/gdb.dwarf2
The File Name Table (offset 0x138):
Entry Dir Time Size Name
1 1 0 0 dw2-symtab-includes.h
...
After expanding all symtabs, we can see the CU listed in the user field of the
PU, and vice-versa the PU listed in the includes of the CU:
...
$ gdb.sh -batch \
-iex "set language c" \
outputs/gdb.dwarf2/dw2-symtab-includes/dw2-symtab-includes \
-ex "maint expand-symtabs" \
-ex "maint info symtabs"
...
{ ((struct compunit_symtab *) 0x394dd60)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x394dea0)
user ((struct compunit_symtab *) 0x394dba0)
}
{ ((struct compunit_symtab *) 0x394dba0)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x394dd10)
user ((struct compunit_symtab *) (null))
( includes
((struct compunit_symtab *) 0x394dd60)
)
}
...
But if we instead only expand the symtab for the dw2-symtab-includes.h file,
the includes and user links are gone:
...
$ gdb -batch \
-iex "set language c" \
outputs/gdb.dwarf2/dw2-symtab-includes/dw2-symtab-includes \
-ex "maint expand-symtabs dw2-symtab-includes.h" \
-ex "maint info symtabs"
...
{ ((struct compunit_symtab *) 0x2728210)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x2728350)
user ((struct compunit_symtab *) (null))
}
{ ((struct compunit_symtab *) 0x2728050)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x27281c0)
user ((struct compunit_symtab *) (null))
}
...
The includes are calculated by process_cu_includes in gdb/dwarf2/read.c.
In the case of expanding all symtabs:
- the CU partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_psymtab::read_symtab
- dwarf2_psymtab::read_symtab calls dwarf2_psymtab::expand_psymtab
- dwarf2_psymtab::read_symtab calls process_cu_includes, and we have the
includes
In the case of expanding the symtab for dw2-symtab-includes.h:
- the dw2-symtab-includes.h partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_include_psymtab::read_symtab
- dwarf2_include_psymtab::read_symtab calls
dwarf2_include_psymtab::expand_psymtab
- dwarf2_include_psymtab::expand_psymtab calls
partial_symtab::expand_dependencies
- partial_symtab::expand_dependencies calls dwarf2_psymtab::expand_psymtab
for the CU partial symtab
- the CU partial symtab is expanded using dwarf2_psymtab::expand_psymtab
- process_cu_includes is never called
Fix this by making sure in dwarf2_include_psymtab::read_symtab that
read_symtab is called for the CU partial symtab.
Tested on x86_64-linux, with native, and target board cc-with-dwz and
cc-with-dwz-m.
In addition, tested test-case with target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/ChangeLog:
2020-04-14 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/25718
* psympriv.h (struct partial_symtab::read_symtab)
(struct partial_symtab::expand_psymtab)
(struct partial_symtab::read_dependencies): Update comments.
* dwarf2/read.c (struct dwarf2_include_psymtab::read_symtab): Call
read_symtab for includer.
(struct dwarf2_include_psymtab::expand_psymtab): Assert false.
(struct dwarf2_include_psymtab::readin_p): Call readin_p () for includer.
(struct dwarf2_include_psymtab::m_readin): Remove.
(struct dwarf2_include_psymtab::includer): New member function.
(dwarf2_psymtab::expand_psymtab): Assert !readin.
gdb/testsuite/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25718
* gdb.dwarf2/dw2-symtab-includes.exp: New file.
|
|
Consider this test-case, consisting of header file hello.h:
...
inline static const char*
foo (void)
{
return "foo";
}
...
and source file hello.c:
...
int
main (void)
{
printf ("hello: %s\n", foo ());
return 0;
}
...
compiled with -g:
...
$ gcc hello.c -g
...
When trying to expand the partial symtab for hello.h:
...
$ gdb -batch \
-iex "set language c" \
a.out \
-ex "maint expand-symtabs hello.h" \
-ex "maint info psymtabs"
...
we in fact find that the partial symtab for hello.h (and corresponding
includer partial symtab hello.c) have not been expanded:
...
{ psymtab hello.h ((struct partial_symtab *) 0x27cf070)
readin no
...
{ psymtab hello.c ((struct partial_symtab *) 0x2cf09e0)
readin no
...
This is due to the recursively_search_psymtabs call in
psym_expand_symtabs_matching:
...
if (recursively_search_psymtabs (ps, objfile, domain,
lookup_name, symbol_matcher))
...
which always returns false for symbolless partial symtabs.
The same problem occurs with CUs where the dwarf is generated by gas
--gdwarf-2 for a foo.S: if we read such a test-case with -readnow, we'll have
a symbolless symtab for foo.S. But if we read the test-case with partial
symtabs, and expand those using "maint expand-symtabs", the foo.S psymtab
remains unexpanded.
Fix this by passing a NULL symbol_matcher and lookup_name to
expand_symtabs_matching in maintenance_expand_symtabs, and skipping the call
to recursively_search_psymtabs if symbol_matcher == NULL and
lookup_name == NULL.
Build and tested on x86_64-linux, with native.
In addition, tested test-case with target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25720
* symmisc.c (maintenance_expand_symtabs): Call expand_symtabs_matching
with NULL symbol_matcher and lookup_name.
* psymtab.c (psym_expand_symtabs_matching): Handle NULL symbol_matcher
and lookup_name.
* dwarf2/read.c (dw2_expand_symtabs_matching)
(dw2_debug_names_expand_symtabs_matching): Same.
* symfile.h (struct quick_symbol_functions::expand_symtabs_matching):
Make lookup_name a pointer. Update comment.
* symtab.c (global_symbol_searcher::expand_symtabs): Handle
lookup_name being a pointer.
* symfile.c (expand_symtabs_matching): Same.
* symfile-debug.c (debug_qf_expand_symtabs_matching): Same.
* linespec.c (iterate_over_all_matching_symtabs): Same.
gdb/testsuite/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25720
* gdb.base/maint-expand-symbols-header-file.c: New test.
* gdb.base/maint-expand-symbols-header-file.exp: New file.
* gdb.base/maint-expand-symbols-header-file.h: New test.
|
