LLD from 11 onwards (https://reviews.llvm.org/D81784) uses -1 to
represent a relocation in .debug_line referencing a discarded symbol.
Recognize -1 to fix gdb.base/break-on-linker-gcd-function.exp when the
linker is a newer LLD.
gdb/ChangeLog:
* dwarf2/read.c (lnp_state_machine::check_line_address): Test -1.
Currently, GDB rejects the (die) reference form while it accepts exprloc
form. It is allowed in DWARF standard. "Table 7.5: Attribute encodings"
in DWARF5 standard. Flang compiler assigns (die) reference to
DW_AT_associated and DW_AT_allocated for some cases.
gdb/ChangeLog
* dwarf2/read.c (set_die_type): Removed conditions to restrict
forms for DW_AT_associated and DW_AT_allocated attributes,
which is already checked in function attr_to_dynamic_prop.
Tom de Vries pointed out that some Rust tests were failing after the
variant part rewrite. He sent an executable, which helped track down
this bug.
quirk_rust_enum was passing 1 to alloc_rust_variant in one case.
However, a comment earlier says:
/* We don't need a range entry for the discriminant, but we do
need one for every other field, as there is no default
variant. */
In this case, we must pass -1 for this parameter. That is what this
patch implements.
gdb/ChangeLog
2020-06-30 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (quirk_rust_enum): Correctly call
alloc_rust_variant for default-less enum.
Add some empty lines at places I forgot in the previous patch.
gdb/ChangeLog:
* dwarf2/loc.c (decode_debug_loclists_addresses): Add empty
lines.
Change-Id: I8a9f3766ede1ce750e0703023285dca873bce0da
I always found that some switch statements in this file were a bit too
packed. I think having empty lines between each case helps with
reading. I'm pushing this as obvious, I hope it won't be too
controversial.
gdb/ChangeLog:
* dwarf2/loc.c (decode_debug_loc_dwo_addresses): Add empty
lines.
(dwarf2_find_location_expression): Likewise.
(call_site_parameter_matches): Likewise.
(dwarf2_compile_expr_to_ax): Likewise.
(disassemble_dwarf_expression): Likewise.
(loclist_describe_location): Likewise.
Change-Id: I381366a0468ff1793faa612c46ef48a9d4773192
This patch fixes an internal error that is triggered when loading the
same binary twice with the index-cache on:
$ ./gdb -q -nx --data-directory=data-directory
(gdb) set index-cache on
(gdb) shell mktemp -d
/tmp/tmp.BLgouVoPq4
(gdb) set index-cache directory /tmp/tmp.BLgouVoPq4
(gdb) file a.out
Reading symbols from a.out...
(gdb) file a.out
Load new symbol table from "a.out"? (y or n) y
Reading symbols from a.out...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2540: internal-error: void create_cus_from_index(dwarf2_per_bfd*, const gdb_byte*, offset_type, const gdb_byte*, offset_type): Assertion `per_bfd->all_comp_units.empty ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is what happens:
1. We load the binary the first time, partial symtabs are created,
per_bfd->all_comp_units is filled from those.
2. Because index-cache is on, we also generate an index in the cache.
3. We load the binary a second time, in dwarf2_initialize_objfile we
check: was an index already loaded for this BFD? No, so we try to
read the index and fill the per-bfd using it. We do find an index,
it's in the cache.
4. The function create_cus_from_index asserts (rightfully) that
per_cu->all_comp_units is empty, and the assertion fails.
This assertion verifies that we are not reading an index for a BFD for
which we have already built partial symtabs or read another index.
The index-cache gives a situation that isn't currently accounted for: a
BFD for which we have built the partial symtabs the first time, but has
an index the second time.
This patch addresses it by checking for the presence of partial symtabs
in dwarf2_initialize_objfile. If there are, we don't try reading the
index.
gdb/ChangeLog:
* dwarf2/read.c (dwarf2_initialize_objfile): Check for presence
of partial symtabs.
gdb/testsuite/ChangeLog:
* gdb.base/index-cache-load-twice.c: New.
* gdb.base/index-cache-load-twice.exp: New.
Change-Id: Ie05474c44823fcdff852b73170dd28dfd66cb6a2
This commit changes the language_data::la_get_symbol_name_matcher
function pointer member variable into a member function of
language_defn.
There should be no user visible changes after this commit.
Before this commit access to the la_get_symbol_name_matcher function
pointer was through the get_symbol_name_matcher function, which looked
something like this (is pseudo-code):
<return-type>
get_symbol_name_matcher (language_defn *lang, <other args>)
{
if (current_language == ada)
current_language->la_get_symbol_name_matcher (<other args>);
else
lang->la_get_symbol_name_matcher (<other args>);
}
In this commit I moved the get_symbol_name_matcher as a non-virtual
function in the language_defn base class, I then add a new virtual
method that is only used from within get_symbol_name_matcher, this can
then be overridden by specific languages as needed. So we now have:
class language_defn
{
<return-type> get_symbol_name_matcher (<args>)
{
if (current_language == ada)
return current_language->get_symbol_name_matcher_inner (<args>);
else
return this->get_symbol_name_matcher_inner (<args>);
}
virtual <return-type> get_symbol_name_matcher_inner (<args>)
{
....
}
}
gdb/ChangeLog:
* ada-lang.c (ada_get_symbol_name_matcher): Update header comment.
(ada_language_data): Delete la_get_symbol_name_matcher
initializer.
(language_defn::get_symbol_name_matcher_inner): New member
function.
* c-lang.c (c_language_data): Delete la_get_symbol_name_matcher
initializer.
(cplus_language_data): Likewise.
(cplus_language::get_symbol_name_matcher_inner): New member
function.
(asm_language_data): Delete la_get_symbol_name_matcher initializer.
(minimal_language_data): Likewise.
* cp-support.h (cp_get_symbol_name_matcher): Update header comment.
* d-lang.c (d_language_data): Delete la_get_symbol_name_matcher
initializer.
* dictionary.c (iter_match_first_hashed): Update call to
get_symbol_name_matcher.
(iter_match_next_hashed): Likewise.
(iter_match_next_linear): Likewise.
* dwarf2/read.c (dw2_expand_symtabs_matching_symbol): Likewise.
* f-lang.c (f_language_data): Delete la_get_symbol_name_matcher
initializer.
(f_language::get_symbol_name_matcher_inner): New member function.
* go-lang.c (go_language_data): Delete la_get_symbol_name_matcher
initializer.
* language.c (default_symbol_name_matcher): Update header comment,
make static.
(language_defn::get_symbol_name_matcher): New definition.
(language_defn::get_symbol_name_matcher_inner): Likewise.
(get_symbol_name_matcher): Delete.
(unknown_language_data): Delete la_get_symbol_name_matcher
initializer.
(auto_language_data): Likewise.
* language.h (language_data): Delete la_get_symbol_name_matcher
field.
(language_defn::get_symbol_name_matcher): New member function.
(language_defn::get_symbol_name_matcher_inner): Likewise.
(default_symbol_name_matcher): Delete declaration.
* linespec.c (find_methods): Update call to
get_symbol_name_matcher.
* m2-lang.c (m2_language_data): Delete la_get_symbol_name_matcher
initializer.
* minsyms.c (lookup_minimal_symbol): Update call to
get_symbol_name_matcher.
(iterate_over_minimal_symbols): Likewise.
* objc-lang.c (objc_language_data): Delete
la_get_symbol_name_matcher initializer.
* opencl-lang.c (opencl_language_data): Likewise.
* p-lang.c (pascal_language_data): Likewise.
* psymtab.c (psymbol_name_matches): Update call to
get_symbol_name_matcher.
* rust-lang.c (rust_language_data): Delete
la_get_symbol_name_matcher initializer.
* symtab.c (symbol_matches_search_name): Update call to
get_symbol_name_matcher.
(compare_symbol_name): Likewise.
Currently the .gdb_index is not enabled for ada executables (PR24713).
Fix this by adding the required support in write_psymbols, similar to how that
is done for .debug_names in debug_names::insert.
Tested on x86_64-linux, with native and target board cc-with-gdb-index.
gdb/ChangeLog:
2020-06-10 Tom de Vries <tdevries@suse.de>
PR ada/24713
* dwarf2/index-write.c (struct mapped_symtab): Add m_string_obstack.
(write_psymbols): Enable .gdb_index for ada.
* dwarf2/read.c: Remove comment stating .gdb_index is unsupported for
ada.
gdb/testsuite/ChangeLog:
2020-06-10 Tom de Vries <tdevries@suse.de>
* gdb.ada/ptype_union.exp: Remove PR24713 workaround.
In commit 9a0bacfb08 "[gdb/symtab] Handle .gdb_index in ada language mode", a
missing part of dw2_map_matching_symbols was added, containing a call to
dw2_expand_symtabs_matching_symbol.
However, the callback passed to that call has one problem: the callback has an
argument "offset_type namei", which is ignored. Instead, match_name is passed
as argument to dw2_symtab_iter_init, where a name lookup is done, which may or
may not yield the same value as namei.
Fix this by creating a new version of dw2_symtab_iter_init that takes a
"offset_type namei" argument instead of "const char *name", and passing namei.
Tested on x86_64-linux, with native and target board cc-with-gdb-index.
gdb/ChangeLog:
2020-06-10 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (dw2_symtab_iter_init_common): Factor out of ...
(dw2_symtab_iter_init): ... here. Add variant with "offset_type
namei" instead of "const char *name" argument.
(dw2_map_matching_symbols): Use "offset_type namei" variant of
dw2_symtab_iter_init.
Remove the `TYPE_FIELD_TYPE` macro, changing all the call sites to use
`type::field` and `field::type` directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD_TYPE): Remove. Change all call sites
to use type::field and field::type instead.
Change-Id: Ifda6226a25c811cfd334a756a9fbc5c0afdddff3
Remove the `FIELD_TYPE` macro, changing all the call sites to use
`field::type` directly.
gdb/ChangeLog:
* gdbtypes.h (FIELD_TYPE): Remove. Change all call sites
to use field::type instead.
Change-Id: I7673fedaa276e485189c87991a9043495da22ef5
Add the `type` and `set_type` methods on `struct field`, in order to
remoremove the `FIELD_TYPE` macro. In this patch, the `FIELD_TYPE`
macro is changed to use `field::type`, so all the call sites that are
useused to set the field's type are changed to use `field::set_type`.
The next patch will remove `FIELD_TYPE` completely.
Note that because of the name clash between the existing field named
`type` and the new method, I renamed the field `m_type`. It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).
gdb/ChangeLog:
* gdbtypes.h (struct field) <type, set_type>: New methods.
Rename `type` field to...
<m_type>: ... this. Change references throughout to use type or
set_type methods.
(FIELD_TYPE): Use field::type. Change call sites that modify
the field's type to use field::set_type instead.
Change-Id: Ie21f866e3b7f8a51ea49b722d07d272a724459a0
Fix/follow-up to commit 17ee85fc2a ("Share DWARF partial symtabs").
In the non-index case, where GDB builds partial symbols from scratch,
two objfiles around the same BFD correctly share partial symtabs. The
first objfile, which has to do all the work, saves a reference to the
created partial symtabs in the shared per_bfd object (at the end of
dwarf2_build_psymtabs). The second objfile, when it reaches
dwarf2_build_psymtabs, sees that there are already partial symtabs built
for this BFD and just uses it.
However, that commit missed implementing the same sharing for cases
where GDB uses .gdb_index or .debug_names to build the partial symtabs.
This patch fixes it by having the first objfile to use the BFD set
per_bfd->partial_symtabs at the end of dwarf2_read_gdb_index /
dwarf2_read_debug_names. For the subsequent objfiles using that BFD,
the partial symtabs are then picked up in dwarf2_initialize_objfile.
This patch adds a test that mimics how the issue was originally
triggered:
1. Load the test file twice, such that the second objfile re-uses the
per_bfd object created for the first objfile.
2. Run to some point where in the backtrace there is a frame for a
function that's in a CU that's not yet read in.
3. Check that this frame's information is complete in the "backtrace"
output.
Step 2 requires an address -> symbol lookup which uses the addrmap at
objfile->partial_symtabs->psymtabs_addrmap. If the
objfile->partial_symtabs link is not properly setup (as is the case
before this patch), the symbol for that frame won't be found and we'll
get a frame with incomplete information.
The test fails without the fix when using boards "cc-with-gdb-index" and
"cc-with-debug-names".
gdb/ChangeLog:
* dwarf2/read.c (dwarf2_read_gdb_index): Save partial_symtabs in
the per_bfd object.
(dwarf2_read_debug_names): Likewise.
(dwarf2_initialize_objfile): Use partial_symtabs from per_bfd
object when re-using a per_bfd object with an index.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/share-psymtabs-bt.exp: New file.
* gdb.dwarf2/share-psymtabs-bt.c: New file.
* gdb.dwarf2/share-psymtabs-bt-2.c: New file.
Change-Id: Ibb26210e2dfc03b80ba9fa56b875ba4cc58c0352
Consider the test-case contained in this patch.
With -readnow, we have two breakpoint locations:
...
$ gdb -readnow -batch breakpoint-locs -ex "b N1::C1::baz" -ex "info break"
Breakpoint 1 at 0x4004cb: N1::C1::baz. (2 locations)
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004004cb in N1::C1::baz() \
at breakpoint-locs.h:6
1.2 y 0x00000000004004f0 in N1::C1::baz() \
at breakpoint-locs.h:6
...
But without -readnow, we have instead only one breakpoint location:
...
$ gdb -batch breakpoint-locs -ex "b N1::C1::baz" -ex "info break"
Breakpoint 1 at 0x4004f0: file breakpoint-locs.h, line 6.
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000004004f0 in N1::C1::baz() \
at breakpoint-locs.h:6
...
The relevant dwarf is this bit:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : breakpoint-locs.cc
<1><f4>: Abbrev Number: 2 (DW_TAG_namespace)
<f5> DW_AT_name : N1
<2><fe>: Abbrev Number: 3 (DW_TAG_class_type)
<ff> DW_AT_name : C1
<3><109>: Abbrev Number: 4 (DW_TAG_subprogram)
<10a> DW_AT_name : baz
<110> DW_AT_linkage_name: _ZN2N12C13bazEv
<2><116>: Abbrev Number: 5 (DW_TAG_subprogram)
<117> DW_AT_name : foo
<11d> DW_AT_linkage_name: _ZN2N13fooEv
<1><146>: Abbrev Number: 8 (DW_TAG_subprogram)
<147> DW_AT_specification: <0x116>
<14b> DW_AT_low_pc : 0x4004c7
<153> DW_AT_high_pc : 0x10
<2><161>: Abbrev Number: 9 (DW_TAG_inlined_subroutine)
<162> DW_AT_abstract_origin: <0x194>
<166> DW_AT_low_pc : 0x4004cb
<16e> DW_AT_high_pc : 0x9
<1><194>: Abbrev Number: 12 (DW_TAG_subprogram)
<195> DW_AT_specification: <0x109>
<199> DW_AT_inline : 3 (declared as inline and inlined)
...
The missing breakpoint location is specified by DIE 0x161, which is ignored by
the partial DIE reader because it's a child of a DW_TAG_subprogram DIE (at
0x146, for foo).
Fix this by not ignoring the DIE during partial DIE reading.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-06-03 Tom de Vries <tdevries@suse.de>
PR symtab/26046
* dwarf2/read.c (scan_partial_symbols): Recurse into DW_TAG_subprogram
children for C++.
(load_partial_dies): Don't skip DW_TAG_inlined_subroutine child of
DW_TAG_subprogram.
gdb/testsuite/ChangeLog:
2020-06-03 Tom de Vries <tdevries@suse.de>
PR symtab/26046
* gdb.cp/breakpoint-locs-2.cc: New test.
* gdb.cp/breakpoint-locs.cc: New test.
* gdb.cp/breakpoint-locs.exp: New file.
* gdb.cp/breakpoint-locs.h: New test.
After the is-stmt support commit:
commit 8c95582da858ac981f689a6f599acacb8c5c490f
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
A regression was observed where a breakpoint could no longer be placed
in some cases.
Consider a line table like this:
File 1: test.c
File 2: test.h
| Addr | File | Line | Stmt |
|------|------|------|------|
| 1 | 1 | 16 | Y |
| 2 | 1 | 17 | Y |
| 3 | 2 | 21 | Y |
| 4 | 2 | 22 | Y |
| 4 | 1 | 18 | N |
| 5 | 2 | 23 | N |
| 6 | 1 | 24 | Y |
| 7 | 1 | END | Y |
|------|------|------|------|
Before the is-stmt patch GDB would ignore any non-stmt lines, so GDB
built two line table structures:
File 1 File 2
------ ------
| Addr | Line | | Addr | Line |
|------|------| |------|------|
| 1 | 16 | | 3 | 21 |
| 2 | 17 | | 4 | 22 |
| 3 | END | | 6 | END |
| 6 | 24 | |------|------|
| 7 | END |
|------|------|
After the is-stmt patch GDB now records non-stmt lines, so the
generated line table structures look like this:
File 1 File 2
------ ------
| Addr | Line | Stmt | | Addr | Line | Stmt |
|------|------|------| |------|------|------|
| 1 | 16 | Y | | 3 | 21 | Y |
| 2 | 17 | Y | | 4 | 22 | Y |
| 3 | END | Y | | 4 | END | Y |
| 4 | 18 | N | | 5 | 23 | N |
| 5 | END | Y | | 6 | END | Y |
| 6 | 24 | Y | |------|------|------|
| 7 | END | Y |
|------|------|------|
The problem is that in 'File 2', end END marker at address 4 causes
the previous line table entry to be discarded, so we actually end up
with this:
File 2
------
| Addr | Line | Stmt |
|------|------|------|
| 3 | 21 | Y |
| 4 | END | Y |
| 5 | 23 | N |
| 6 | END | Y |
|------|------|------|
When a user tries to place a breakpoint in file 2 at line 22, this is
no longer possible.
The solution I propose here is that we ignore line table entries that
would trigger a change of file if:
1. The new line being added is at the same address as the previous
line, and
2. We have previously seen an is-stmt line at the current address.
The result of this is that GDB switches file, and knows that some line
entry (or entries) are going to be discarded, prefer to keep is-stmt
lines and discard non-stmt lines.
After this commit the lines tables are now:
File 1 File 2
------ ------
| Addr | Line | Stmt | | Addr | Line | Stmt |
|------|------|------| |------|------|------|
| 1 | 16 | Y | | 3 | 21 | Y |
| 2 | 17 | Y | | 4 | 22 | Y |
| 3 | END | Y | | 5 | 23 | N |
| 5 | END | Y | | 6 | END | Y |
| 6 | 24 | Y | |------|------|------|
| 7 | END | Y |
|------|------|------|
We've lost the non-stmt entry for file 1, line 18, but retained the
is-stmt entry for file 2, line 22. The user can now place a
breakpoint at that location.
One problem that came from this commit was the test
gdb.cp/step-and-next-inline.exp, which broke in several places. After
looking at this test again I think that in some cases this test was
only ever passing by pure luck. The debug GCC is producing for this
test is pretty broken. I raised this GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
for this and disabled one entire half of the test. There are still
some cases in here that do pass, and if/when GCC is fixed it would be
great to enable this test again.
gdb/ChangeLog:
* dwarf2/read.c (class lnp_state_machine) <m_last_address>: New
member variable.
<m_stmt_at_address>: New member variable.
(lnp_state_machine::record_line): Don't record some lines, update
tracking of is_stmt at the same address.
(lnp_state_machine::lnp_state_machine): Initialise new member
variables.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.exp (do_test): Skip all tests in the
use_header case.
* gdb.dwarf2/dw2-inline-header-1.exp: New file.
* gdb.dwarf2/dw2-inline-header-2.exp: New file.
* gdb.dwarf2/dw2-inline-header-3.exp: New file.
* gdb.dwarf2/dw2-inline-header-lbls.c: New file.
* gdb.dwarf2/dw2-inline-header.c: New file.
* gdb.dwarf2/dw2-inline-header.h: New file.
While doing the psymtab-sharing patchset, I avoided renaming variables
unnecessarily to avoid adding noise to patches, but I'd like to do it
now. Basically, we have these dwarf2 per-something structures:
- dwarf2_per_objfile
- dwarf2_per_bfd
- dwarf2_per_cu_data
I named the instances of dwarf2_per_bfd `per_bfd` and most of instances
of dwarf2_per_cu_data are called `per_cu`. Most pre-existing instances
of dwarf2_per_objfile are named `dwarf2_per_objfile`. For consistency
with the other type, I'd like to rename them to just `per_objfile`. The
`dwarf2_` prefix is superfluous, since it's already clear we are in
dwarf2 code. It also helps reducing the line wrapping by saving 7
precious columns.
gdb/ChangeLog:
* dwarf2/comp-unit.c, dwarf2/comp-unit.h, dwarf2/index-cache.c,
dwarf2/index-cache.h, dwarf2/index-write.c,
dwarf2/index-write.h, dwarf2/line-header.c,
dwarf2/line-header.h, dwarf2/macro.c, dwarf2/macro.h,
dwarf2/read.c, dwarf2/read.h: Rename struct dwarf2_per_objfile
variables and fields from `dwarf2_per_objfile` to just
`per_objfile` throughout.
Change-Id: I3c45cdcc561265e90df82cbd36b4b4ef2fa73aef
Add a comment to clarify why we temporarily override some of the
context's fields, and especially the per_objfile field. A longer
explanation can be found in this previous commit
44486dcf19b ("gdb: use caller objfile in dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value")
gdb/ChangeLog:
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<push_dwarf_reg_entry_value>: Add comment.
Change-Id: I60c6e1062799f729b30a9db78bcb6448783324b4
In commit
89b07335fe ("Add dwarf2_per_objfile to dwarf_expr_context and dwarf2_frame_cache")
I replaced the offset property of dwarf_expr_context by a per_objfile
property (since we can get the text offset from the objfile). The
previous code in dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value
(dwarf_evaluate_loc_desc derives from dwarf_expr_context) did
temporarily override the offset property while evaluating a DWARF
sub-expression. I speculated that this sub-expression always came from
the same objfile as the outer expression, so I didn't see the need to
temporarily override the per_objfile property in the new code. A later
commit:
9f47c70716 ("Remove dwarf2_per_cu_data::objfile ()")
added the following assertion to verify this:
gdb_assert (this->per_objfile == caller_per_objfile);
It turns out that this is not true. Call sites can refer to function in
another objfile, and therefore the caller's objfile can be different
from the callee's objfile. This can happen when the call site DIE in the
DWARF represents a function call done through a function pointer. The
DIE can't describe statically which function is being called, since it's
variable and not known at compile time. Instead, it provides an
expression that evaluates to the address of the function being called.
In this case, the called function can very well be in a separate
objfile.
Fix this by overriding the per_objfile property while evaluating the
sub-expression.
This was exposed by the gdb.base/catch-load.exp test failing on openSUSE
Tumbleweed with the glibc debug info installed. It was also reported to
fail on Fedora.
When I investigated the problem, the particular call site on which we
did hit the assert was coming from this DIE, in
/usr/lib/debug/lib64/libc-2.31.so-2.31-5.1.x86_64.debug on openSUSE
Tumbleweed:
0x0091aa10: DW_TAG_GNU_call_site
DW_AT_low_pc [DW_FORM_addr] (0x00000000001398e0)
DW_AT_GNU_call_site_target [DW_FORM_exprloc] (DW_OP_fbreg -272, DW_OP_deref)
DW_AT_sibling [DW_FORM_ref4] (0x0091aa2b)
And for you curious out there, this call site is found in this function:
0x0091a91d: DW_TAG_subprogram
DW_AT_external [DW_FORM_flag_present] (true)
DW_AT_name [DW_FORM_strp] ("_dl_catch_exception")
DW_AT_decl_file [DW_FORM_data1] ("/usr/src/debug/glibc-2.31-5.1.x86_64/elf/dl-error-skeleton.c")
...
Which is a function that indeed uses a function pointer.
gdb/ChangeLog:
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<push_dwarf_reg_entry_value>: Remove assert. Override
per_objfile with caller_per_objfile.
Change-Id: Ib227d767ce525c10607ab6621a373aaae982c67a
There's a PR gold/15646 - "gold-generated .gdb_index has duplicated
symbols that gdb-generated index doesn't", that causes gold to generate
duplicate symbols in the index.
F.i., a namespace N1 declared in a header file can be listed for two CUs that
include the header file:
...
[759] N1:
2 [global type]
3 [global type]
...
This causes a gdb performance problem: f.i. when attempting to set a
breakpoint on a non-existing function N1::misspelled, the symtab for both CUs
will be expanded.
Gdb contains a workaround for this, added in commit 8943b87476 "Work around
gold/15646", that skips duplicate global symbols in the index.
However, the workaround does not check for the symbol kind ("type" in the
example above).
Make the workaround more precise by limiting it to symbol kind "type".
Tested on x86_64-linux, with target boards cc-with-gdb-index and
gold-gdb-index.
gdb/ChangeLog:
2020-05-28 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (dw2_symtab_iter_next, dw2_expand_marked_cus): Limit
PR gold/15646 workaround to symbol kind "type".
An earlier patch added the add_partial_symbol helper function to
dwarf2/read.c. However, a couple of calls to add_psymbol_to_list were
left in place. It turns out that these calls slow down partial symbol
reading, because they still go via the path that tries to needlessly
demangle already-demangled names.
This patch improves the performance of partial symbol reading by
changing this code to use add_partial_symbol instead.
The run previous to this had times of (see the first patch in the
series for an explanation):
gdb 1.64
libxul 1.99
Ada 2.47
This patch improves the times to:
gdb 1.47
libxul 1.89
Ada 2.39
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (load_partial_dies): Use add_partial_symbol.
Profiling showed that calls to abbrev_table::lookup_abbrev were "too
visible". As these are just forwarding calls to the hash table, this
patch inlines the lookup. Also, htab_find_with_hash is used, avoiding
another call.
The run previous to this had times of (see the first patch in the
series for an explanation):
gdb 1.69
libxul 2.02
Ada 2.52
This patch improves the times to:
gdb 1.64
libxul 1.99
Ada 2.47
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/abbrev.h (struct abbrev_table) <lookup_abbrev>: Inline.
Use htab_find_with_hash.
<add_abbrev>: Remove "abbrev_number" parameter.
* dwarf2/abbrev.c (abbrev_table::add_abbrev): Remove
"abbrev_number" parameter. Use htab_find_slot_with_hash.
(hash_abbrev): Add comment.
(abbrev_table::lookup_abbrev): Move to header file.
(abbrev_table::read): Update.
Currently the name of a partial DIE is computed eagerly. However, the
name is not always needed. This patch changes partial DIEs to compute
their name lazily, improving performance by avoiding unnecessary name
computations.
The run previous to this had times of (see the first patch in the
series for an explanation):
gdb 1.88
libxul 2.11
Ada 2.60
This patch improves the times to:
gdb 1.69
libxul 2.02
Ada 2.52
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (struct partial_die_info) <name>: Declare new
method.
<canonical_name>: New member.
<raw_name>: Rename from "name".
(partial_die_info): Initialize canonical_name.
(scan_partial_symbols): Check raw_name.
(partial_die_parent_scope, partial_die_full_name)
(add_partial_symbol, add_partial_subprogram)
(add_partial_enumeration, load_partial_dies): Use "name" method.
(partial_die_info::name): New method.
(partial_die_info::read, guess_partial_die_structure_name)
(partial_die_info::fixup): Update.
This inlines a couple of methods on struct attribute, improving the
performance of DWARF partial symbol reading. These methods were
discovered as hot spots using callgrind.
For this patch, and for all the patches in this series, I tested gdb's
performance on three programs:
1. gdb itself -- I built gdb and copied it to /tmp, ensuring that the
same version was used in all tests.
2. The system libxul.so, the main library of Firefox. I installed the
separate debuginfo and ensured that gdb read it.
3. A large-ish Ada program that I happen to have.
I ran gdb 10 times like:
/bin/time -f %e \
./gdb/gdb --data-directory ./gdb/data-directory -nx \
-iex 'set debug-file-directory /usr/lib/debug' \
-batch $X
... where $X was the test executable. Then I computed the mean time.
This was all done with a standard (-g -O2) build of gdb.
The baseline times were
gdb 1.90
libxul 2.12
Ada 2.61
This patch brings the numbers down to
gdb 1.88
libxul 2.11
Ada 2.60
Not a huge change, but still visible in the results.
gdb/ChangeLog
2020-05-27 Tom Tromey <tromey@adacore.com>
* dwarf2/attribute.h (struct attribute) <form_is_ref>: Inline.
<get_ref_die_offset>: Inline.
<get_ref_die_offset_complaint>: New method.
* dwarf2/attribute.c (attribute::form_is_ref): Move to header.
(attribute::get_ref_die_offset_complaint): Rename from
get_ref_die_offset. Just issue complaint.
This changes the DWARF reader to share partial symtabs (or indices if
they are available) across objfiles. This has a few parts.
* If multiple objfiles backed by the same BFD can share partial symtabs
(see below), a single dwarf2_per_bfd is created. It is stored in the
per-bfd `dwarf2_per_bfd_bfd_data_key` registry. Multiple
dwarf2_per_objfile objects will point to the same instance. The
lifetime of these dwarf2_per_bfd objects is naturally handled. When
all the objfiles using the BFD are destroyed, the BFD's refount drops
to 0, which triggers the removal of the corresponding dwarf2_per_bfd
object from the registry and its destruction.
* If multiple objfiles backed by the same BFD can't share partial
symtabs (see below), one dwarf2_per_bfd object is created for each
objfile. Each dwarf2_per_objfile will point to their own instance of
dwarf2_per_bfd. These instances of dwarf2_per_bfd are kept in a
per-objfile registry, meaning that when the objfile gets destroyed,
the dwarf2_per_bfd instance gets destroyed as well.
* objfile::partial_symtabs is changed to be a shared_ptr again. This
lets us stash a second reference in dwarf2_per_bfd; if the DWARF
data is being shared, we can simply copy this value to the new
objfile.
* Two dwarf2_per_objfile objects backed by the same BFD may share a
dwarf2_per_bfd instance if:
* No other symbol reader has found symbols, and
* No BFD section rqeuires relocation
gdb/ChangeLog:
YYYY-MM-DD Tom Tromey <tom@tromey.com>
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
* objfiles.h (struct objfile) <partial_symtabs>: Now a
shared_ptr.
* dwarf2/read.h (struct dwarf2_per_objfile) <partial_symtabs>: New
member.
* dwarf2/read.c (dwarf2_per_bfd_bfd_data_key,
dwarf2_per_bfd_objfile_data_key>: New globals.
(dwarf2_has_info): Use shared dwarf2_per_bfd if possible.
(dwarf2_get_section_info): Use get_dwarf2_per_objfile.
(dwarf2_initialize_objfile): Consider cases where per_bfd can be
shared.
(dwarf2_build_psymtabs): Set objfile::partial_symtabs and
short-circuit when sharing.
(dwarf2_build_psymtabs): Set dwarf2_per_objfile::partial_symtabs.
(dwarf2_psymtab::expand_psymtab): Use free_cached_comp_units.
Change-Id: I868c64448589102ab8cbb8f06c31a8de50a14004
The `line_header_hash` field of `struct dwarf2_per_bfd` contains some
`struct line_header` objects. A `struct line_header` objects contains
some `file_entry` objects. A `file_entry` object contains a pointer to
the `symtab` object created from it. The `line_header_hash` is
therefore ultimately objfile-dependent and can't be shared as-is between
objfiles.
Move it from `dwarf2_per_bfd` to `dwarf2_per_objfile`.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_bfd) <line_header_hash>: Move
to...
(struct dwarf2_per_objfile) <line_header_hash>: ... here.
* dwarf2/read.c (handle_DW_AT_stmt_list): Update.
Change-Id: I8d2ee04df4f4847c2db99061fc976c35af98ac71
mapped_debug_names currently has a dwarf2_per_objfile field. Since we
want it to become objfile-independent, this field must be removed.
This patch removes it, and then arranges for all methods that needed it
to accept a dwarf2_per_objfile parameter. This trickles down at various
places, like the dw2_debug_names_iterator type.
Ultimately, the objfile only seems to be needed because we might need to
read a string from the string section. For that, we might need to read
in the section, and if it's a relocatable section, the objfile is needed
in order to do the relocation. This pattern happens often (that we to
pass an objfile only because a section might be read). I think it's a
bit ugly, but I don't have a good alternative right now.
gdb/ChangeLog:
* dwarf2/read.c (struct mapped_index_base) <symbol_name_at,
build_name_components, find_name_components_bounds>:
Add per_objfile parameter.
(struct mapped_index) <symbol_name_at>: Likewise.
(struct mapped_debug_names): Remove constructor.
<dwarf2_per_objfile>: Remove field.
<namei_to_name, symbol_name_at>: Add per_objfile parameter.
(mapped_index_base::find_name_components_bounds,
mapped_index_base::build_name_components,
dw2_expand_symtabs_matching_symbol): Likewise.
(class mock_mapped_index) <symbol_name_at>: Likewise.
(check_match): Likewise.
(check_find_bounds_finds): Likewise.
(test_mapped_index_find_name_component_bounds): Update.
(CHECK_MATCH): Update.
(dw2_expand_symtabs_matching): Update.
(class dw2_debug_names_iterator) <dw2_debug_names_iterator>: Add
per_objfile parameter.
<find_vec_in_debug_names>: Likewise.
<m_per_objfile>: New field.
(mapped_debug_names::namei_to_name): Add dwarf2_per_objfile
parameter.
(dw2_debug_names_iterator::find_vec_in_debug_names): Likewise.
(dw2_debug_names_iterator::next): Update.
(dw2_debug_names_lookup_symbol): Update.
(dw2_debug_names_expand_symtabs_for_function): Update.
(dw2_debug_names_map_matching_symbols): Update.
(dw2_debug_names_expand_symtabs_matching): Update.
(dwarf2_read_debug_names): Update.
Change-Id: I00ee0d939390d353442675c7d400a261307c57a1
The dwarf2_per_cu_data type is going to become objfile-independent,
while the dwarf2_cu type will stay object-dependent. This patch removes
the backlink from dwarf2_per_cu_data to dwarf2_cu, in favor of the
dwarf2_per_objfile::m_dwarf2_cus map. It maps dwarf2_per_cu_data
objects to the corresponding dwarf2_cu objects for this objfile. If a
CU has been read in in the context of this objfile, then an entry will
be present in the map.
The dwarf2_cu objects that are read in are currently kept in a linked
list rooted in the dwarf2_per_bfd. Except that the dwarf2_cu objects
are not simply linked together, they are interleaved with their
corresponding dwarf2_per_cu_data objects. So if we have CUs A and B
read in, the dwarf2_per_bfd::read_in_chain will point to a chain like
this (DPCD == dwarf2_per_cu_data, DC == dwarf2_cu):
DPCD A -> DC A -> DPCD B -> DC B
Obviously, this can't stay as is, since a same CU can be read in for an
objfile but not read in for another objfile sharing the same BFD, and
the dwarf2_per_cu_data::cu link is removed. This is all replaced by
the dwarf2_per_objfile::m_dwarf2_cus map.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_cu): Forward-declare.
(struct dwarf2_per_bfd) <free_cached_comp_units>: Remove,
move to dwarf2_per_objfile.
<read_in_chain>: Remove.
(struct dwarf2_per_objfile) <get_cu, set_cu, remove_cu,
remove_all_cus, age_comp_units>: New methods.
<m_dwarf2_cus>: New member.
(struct dwarf2_per_cu_data) <cu>: Remove.
* dwarf2/read.c (struct dwarf2_cu) <read_in_chain>: Remove.
(age_cached_comp_units, free_one_cached_comp_unit): Remove,
moved to methods of dwarf2_per_objfile.
(dwarf2_clear_marks): Remove.
(dwarf2_queue_item::~dwarf2_queue_item): Update.
(dwarf2_per_bfd::~dwarf2_per_bfd): Don't free dwarf2_cus.
(dwarf2_per_bfd::free_cached_comp_units): Remove.
(dwarf2_per_objfile::remove_all_cus): New.
(class free_cached_comp_units) <~free_cached_comp_units>:
Update.
(load_cu): Update.
(dw2_do_instantiate_symtab): Adjust.
(fill_in_sig_entry_from_dwo_entry): Adjust.
(cutu_reader::init_tu_and_read_dwo_dies): Update.
(cutu_reader::cutu_reader): Likewise.
(cutu_reader::keep): Use dwarf2_per_objfile::set_cu.
(cutu_reader::cutu_reader): Use dwarf2_per_objfile::get_cu.
(process_psymtab_comp_unit): Use dwarf2_per_objfile::remove_cu
and dwarf2_per_objfile::age_comp_units.
(load_partial_comp_unit): Update.
(maybe_queue_comp_unit): Use dwarf2_per_objfile::get_cu.
(process_queue): Likewise.
(find_partial_die): Use dwarf2_per_objfile::get_cu instead of cu
backlink.
(dwarf2_read_addr_index): Likewise.
(follow_die_offset): Likewise.
(dwarf2_fetch_die_loc_sect_off): Likewise.
(dwarf2_fetch_constant_bytes): Likewise.
(dwarf2_fetch_die_type_sect_off): Likewise.
(follow_die_sig_1): Likewise.
(load_full_type_unit): Likewise.
(read_signatured_type): Likewise.
(dwarf2_cu::dwarf2_cu): Don't set cu field.
(dwarf2_cu::~dwarf2_cu): Remove.
(dwarf2_per_objfile::get_cu): New.
(dwarf2_per_objfile::set_cu): New.
(age_cached_comp_units): Rename to...
(dwarf2_per_objfile::age_comp_units): ... this. Adjust
to std::unordered_map.
(free_one_cached_comp_unit): Rename to...
(dwarf2_per_objfile::remove_cu): ... this. Adjust
to std::unordered_map.
(dwarf2_per_objfile::~dwarf2_per_objfile): New.
(dwarf2_mark_helper): Use dwarf2_per_objfile::get_cu, expect
a dwarf2_per_objfile in data.
(dwarf2_mark): Pass dwarf2_per_objfile in data to htab_traverse.
(dwarf2_clear_marks): Remove.
Change-Id: Ia33ac71c79b2de4710569008e22a6563a1505cde
It is possible, seemingly for a special case described in
find_partial_die, for cutu_reader to re-use an existing dwarf2_cu
instead of creating a new one. This happens when running this test, for
example:
make check TESTS="gdb.dwarf2/fission-reread.exp"
Right now the, `use_existing_cu` flag tells cutu_reader to use the
dwarf2_cu object at dwarf2_per_cu_data::cu. However, we'll remove that
field, so we need to find another solution.
This situation arises when some caller up the stack has already created
the dwarf2_cu to read a dwarf2_per_cu_data, but needs to re-read it with
some other parameters. Therefore, it's possible to just have that
caller pass down the dwarf2_cu object to use as a `existing_cu`
parameter. If `existing_cu` is NULL, it tells cutu_reader that it needs
to instantiate a new one.
gdb/ChangeLog:
* dwarf2/read.c (class cutu_reader) <cutu_reader>: Replace
`int use_existing_cu` parameter with `dwarf2_cu *existing_cu`.
(init_tu_and_read_dwo_dies): Likewise.
(cutu_reader::init_tu_and_read_dwo_dies): Likewise.
(cutu_reader::cutu_reader): Likewise.
(load_partial_comp_unit): Likewise.
(process_psymtab_comp_unit): Update.
(build_type_psymtabs_1): Update.
(process_skeletonless_type_unit): Update.
(load_full_comp_unit): Update.
(find_partial_die): Update.
(dwarf2_read_addr_index): Update.
(read_signatured_type): Update.
Change-Id: Id03e3bc3de3cf99d9e4b4080ad83b029c93bf434
The per_cu_header_read_in function allows obtaining a filled
comp_unit_head object for a given dwarf2_per_cu_data object. If a
dwarf2_cu object exists for this dwarf2_per_cu_data, then it just
returns a pointer to the comp_unit_head from that dwarf2_cu. Otherwise,
it reads the header into a temporary buffer provided by the caller, and
returns a pointer to that.
Since the dwarf2_per_cu_data::cu link is going to be removed
(dwarf2_per_cu_data will become objfile-independent while dwarf2_cu
stays objfile-dependent), we cannot rely anymore on returning the header
from the dwarf2_cu object.
The not too complex solution implemented by this patch is to keep a copy
of the header in the dwarf2_per_cu_data object, independent from the
copy in dwarf2_cu. The new copy is only used in the addr_size,
offset_size and ref_addr_size methods of dwarf2_per_cu_data.
There's nothing intrinsic to the comp_unit_head object that prevents it
to be shared between two dwarf2_cu objects (belonging to different
objfiles) representing the same CU. In other words, I think we could
eventually get rid of the copy in dwarf2_cu to only keep the one in
dwarf2_per_cu_data. It is not trivial, however, so I have decided not
to do it for the moment.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <m_header,
m_header_read_in>: New fields.
<get_header>: New method.
* dwarf2/read.c (per_cu_header_read_in): Remove.
(dwarf2_per_cu_data::get_header): New.
(dwarf2_per_cu_data::addr_size): Update.
(dwarf2_per_cu_data::offset_size): Update.
(dwarf2_per_cu_data::ref_addr_size): Update.
Change-Id: Id7541fca7562843eba110ece21c4df38d45fca23
In a subsequent patch, the dwarf2_per_cu_data::cu link will be removed.
dwarf2_cu objects will instead need to be looked up from a per-objfile
map, using the dwarf2_per_cu_data object as the key.
To make it easier for some callers, this patch makes load_cu return the
dwarf2_cu it creates. If the caller needs to use the created dwarf2_cu,
it will have it available right away, rather than having to do a map
lookup.
At the same time, this allows changing queue_and_load_all_dwo_tus to
take a dwarf2_cu instead of a dwarf2_per_cu_data.
gdb/ChangeLog:
* dwarf2/read.c (load_cu): Return dwarf2_cu.
(dw2_do_instantiate_symtab): Update.
(queue_and_load_all_dwo_tus): Change parameter from
dwarf2_per_cu_data to dwarf2_cu.
(dwarf2_fetch_die_loc_sect_off): Update.
(dwarf2_fetch_constant_bytes): Update.
(dwarf2_fetch_die_type_sect_off): Update.
Change-Id: I8a04c5d1b8cc661b8203f97999258ba8e04e1765
These two functions work on a dwarf2_cu. It is currently obtained from
the per_cu->cu link, which we want to remove. Make them accept the
dwarf2_cu directly as a parameter. This moves the per_cu->cu references
one level up, but that one will be removed too in a subsequent patch.
gdb/ChangeLog:
* dwarf2/read.c (process_full_comp_unit,
process_full_type_unit): Remove per_cu, per_objfile paramters.
Add dwarf2_cu parameter.
(process_queue): Update.
Change-Id: I1027d36986073ac991e198e06f9d51341dc19c6e
All these functions actually only need to receive a dwarf2_per_bfd, pass
that instead of dwarf2_per_objfile.
gdb/ChangeLog:
* dwarf2/read.c (create_cu_from_index_list): Replace
dwarf2_per_objfile parameter with dwarf2_per_bfd.
(create_cus_from_index_list): Likewise.
(create_cus_from_index): Likewise.
(create_signatured_type_table_from_index): Likewise.
(create_cus_from_debug_names_list): Likewise.
(create_cus_from_debug_names): Likewise.
(dwarf2_read_gdb_index): Update.
(dwarf2_read_debug_names): Update.
Change-Id: I8cd7dc04bf815723a48745e7e9b283663dccc1ac
signatured_type has a link to the "struct type". However, types are
inherently objfile-specific, so once sharing is implemented, this will
be incorrect.
This patch moves the type to a new map in the DWARF unshareable
object.
gdb/ChangeLog:
YYYY-MM-DD Tom Tromey <tom@tromey.com>
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
* dwarf2/read.h (struct dwarf2_per_objfile)
<get_type_for_signatured_type, set_type_for_signatured_type>:
New methods.
<m_type_map>: New member.
(struct signatured_type) <type>: Remove.
* dwarf2/read.c
(dwarf2_per_objfile::get_type_for_signatured_type,
dwarf2_per_objfile::set_type_for_signatured_type): New.
(get_signatured_type): Use new methods.
Change-Id: I765ae3c43fae1064f51ced352167a57638609f02
type_unit_group has links to the compunit_symtab and other symtabs.
However, once this object is shared across objfiles, this will no
longer be ok.
This patch introduces a new type_unit_group_unshareable and arranges to
store a map from type unit groups to type_unit_group_unshareable objects
in dwarf2_per_objfile.
gdb/ChangeLog:
YYYY-MM-DD Tom Tromey <tom@tromey.com>
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
* dwarf2/read.h (struct type_unit_group_unshareable): New.
(struct dwarf2_per_objfile) <type_units>: New member.
<get_type_unit_group_unshareable>: New method.
* dwarf2/read.c (struct type_unit_group) <compunit_symtab,
num_symtabs, symtabs>: Remove; move to
type_unit_group_unshareable.
(dwarf2_per_objfile::get_type_unit_group_unshareable): New.
(process_full_type_unit, dwarf2_cu::setup_type_unit_groups)
(dwarf2_cu::setup_type_unit_groups): Use type_unit_group_unshareable.
Change-Id: I1fec2fab59e0ec40fee3614fc821172a469c0e41
This patch removes the remaining references to that field in obvious
ways (the same object is already available some other way in these
contexts).
gdb/ChangeLog:
* dwarf2/read.c (process_psymtab_comp_unit): Remove reference to
dwarf2_per_cu_data::dwarf2_per_objfile.
(compute_compunit_symtab_includes): Likewise.
(dwarf2_cu::start_symtab): Likewise.
Change-Id: I965700fa793d8457711a2d6ae448aaefd779eb96
Since dwarf2_per_cu_data objects are going to become
objfile-independent, the backlink from dwarf2_per_cu_data to one
particular objfile must be removed. Instead, users of
dwarf2_per_cu_data that need an objfile must know from somewhere else in
the context of which objfile they are using this CU.
This also helps remove a dwarf2_per_cu_data::dwarf2_per_objfile
reference (from where the objfile was obtained).
Note that the dwarf2_per_cu_data::objfile method has a special case to
make sure to return the main objfile, if the objfile associated to the
dwarf2_per_cu_data is a separate debug objfile. I don't really know if
this is necessary: I ignored that, and didn't see any regression when
testing with the various Dejagnu boards with separate debug info, so I
presume it wasn't needed. If it turns out this was needed, then we can
have a helper method on the objfile type for that.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <objfile>: Remove.
* dwarf2/read.c (dwarf2_compute_name): Pass per_objfile down.
(read_call_site_scope): Assign per_objfile.
(dwarf2_per_cu_data::objfile): Remove.
* gdbtypes.h (struct call_site) <per_objfile>: New member.
* dwarf2/loc.h (dwarf2_evaluate_loc_desc): Add
dwarf2_per_objfile parameter.
* dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Add
dwarf2_per_objfile parameter.
(dwarf_expr_reg_to_entry_parameter): Add output
dwarf2_per_objfile parameter.
(locexpr_get_frame_base): Update.
(class dwarf_evaluate_loc_desc) <get_tls_address>: Update.
<push_dwarf_reg_entry_value>: Update.
<call_site_to_target_addr>: Update.
(dwarf_entry_parameter_to_value): Add dwarf2_per_objfile
parameter.
(value_of_dwarf_reg_entry): Update.
(rw_pieced_value): Update.
(indirect_synthetic_pointer): Update.
(dwarf2_evaluate_property): Update.
(dwarf2_loc_desc_get_symbol_read_needs): Add dwarf2_per_objfile
parameter.
(locexpr_read_variable): Update.
(locexpr_get_symbol_read_needs): Update.
(loclist_read_variable): Update.
Change-Id: Idb40d1a94995af305054d463967bb6ce11a08f25
This method simply returns the text offset of the objfile associated to
the dwarf2_per_cu_data object. Since dwarf2_per_cu_data objects are
going to become objfile-independent, we can't keep this method. This
patch removes it.
Existing callers need to figure out the in the context of which objfile
this is being used, and call text_offset on it. Typically, this comes
from a symbol baton, where we store the corresponding
dwarf2_per_objfile.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <text_offset>:
Remove.
* dwarf2/read.c (dwarf2_per_cu_data::text_offset): Remove.
* dwarf2/loc.c (dwarf2_find_location_expression): Update.
(dwarf2_compile_property_to_c): Update.
(dwarf2_compile_expr_to_ax): Add dwarf2_per_objfile parameter,
use text offset from objfile.
(locexpr_tracepoint_var_ref): Update.
(locexpr_generate_c_location): Update.
(loclist_describe_location): Update.
(loclist_tracepoint_var_ref): Update.
* dwarf2/compile.h (compile_dwarf_bounds_to_c): Add
dwarf2_per_objfile parameter.
* dwarf2/loc2c.c (do_compile_dwarf_expr_to_c): Likewise,
use text offset from objfile.
(compile_dwarf_expr_to_c): Add dwarf2_per_objfile parameter.
Change-Id: I56b01ba294733362a3562426a96d48ae051a776f
Evaluating DWARF expressions (such as location expressions) requires
knowing about the current objfile. For example, it may call functions
like dwarf2_fetch_die_loc_sect_off, which currently obtain the
dwarf2_per_objfile object it needs from the dwarf2_per_cu_data object.
However, since we are going to remove this
dwarf2_per_cu_data::dwarf2_per_objfile link, these functions will need
to obtain the current dwarf2_per_objfile by parmeter.
If we go up the stack, we see that the DWARF expression contexts
(dwarf_expr_context and the classes that derive from it) need to store
the dwarf2_per_objfile, to be able to pass it to those functions that
will need it.
This patch adds a constructor to all these dwarf_expr_context variants,
accepting a dwarf2_per_objfile parameter. This dwarf2_per_objfile
generally comes from a symbol baton created earlier.
For frame-related expressions, the dwarf2_per_objfile object must be
passed through the dwarf2_frame_cache object. This lead to the
dwarf2_frame_find_fde function returning (by parameter) a
dwarf2_per_objfile object. I then realized that this made the existing
"out_offset" parameter redundant. This offset is
`objfile->text_section_offset ()`, so it can be recomputed from the
dwarf2_per_objfile object at any time. I therefore opted to remove this
output parameter, as well as the offset field of dwarf2_frame_cache.
*Note*, there's one spot I'm particularly unsure about. In
dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value, we would save and
overwrite the offset value in the context, along with a bunch of other
state. This is because we might be about to evaluate something in a
different CU that the current one. If the two CUs are in the same
objfile, then the text_offset is the same, as it's a property of the
objfile. However, if the two CUs are possibly in different objfiles,
then it means the text_offsets are different. It would also mean we
would need to save and restore the dwarf2_per_objfile in the context.
Is that even possible?
gdb/ChangeLog:
* dwarf2/expr.h (struct dwarf_expr_context)
<dwarf_expr_context>: Add dwarf2_per_objfile parameter.
<offset>: Remove.
<per_objfile>: New member.
* dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): Add
dwarf2_per_objfile parameter. Don't set offset, set
per_objfile.
(dwarf_expr_context::execute_stack_op): Use offset from objfile.
* dwarf2/frame.c (dwarf2_frame_find_fde): Return (by parameter)
a dwarf2_per_objfile object instead of an offset.
(class dwarf_expr_executor) <dwarf_expr_executor>: Add
constructor.
(execute_stack_op): Add dwarf2_per_objfile parameter, pass it
to dwarf2_expr_executor constructor. Don't set offset.
(dwarf2_fetch_cfa_info): Update.
(struct dwarf2_frame_cache) <text_offset>: Remove.
<per_objfile>: New field.
(dwarf2_frame_cache): Update.
(dwarf2_frame_prev_register): Update.
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<dwarf_evaluate_loc_desc>: Add constructor.
(dwarf2_evaluate_loc_desc_full): Update.
(dwarf2_locexpr_baton_eval): Update.
(class symbol_needs_eval_context) <symbol_needs_eval_context>:
Add constructor.
(dwarf2_loc_desc_get_symbol_read_needs): Update.
Change-Id: I14df060669cc36ad04759f1708c6d7b1fda77727
These methods rely on the current objfile to create types based on it.
Since dwarf2_per_cu_data is to become objfile-independent, these methods
need to mvoe.
int_type can be in dwarf2_per_objfile, as it only requires knowing about
the objfile.
addr_sized_int_type and addr_type also need to know about the DWARF
address type size, which is CU-specific. The dwarf2_cu objects seems
like a good place for it, as it knows both about the current objfile and
the current CU.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <addr_type,
addr_sized_int_type>: Move to dwarf2_cu.
<int_type>: Move to dwarf2_per_objfile.
(struct dwarf2_per_objfile) <int_type>: Move here.
* dwarf2/read.c (struct dwarf2_cu) <addr_type,
addr_sized_int_type>: Move here.
(read_func_scope): Update.
(read_array_type): Update.
(read_tag_string_type): Update.
(attr_to_dynamic_prop): Update.
(dwarf2_per_cu_data::int_type): Rename to...
(dwarf2_per_objfile::int_type): ... this.
(dwarf2_per_cu_data::addr_sized_int_type): Rename to...
(dwarf2_cu::addr_sized_int_type): ... this.
(read_subrange_type): Update.
(dwarf2_per_cu_data::addr_type): Rename to...
(dwarf2_cu::addr_type): ... this.
(set_die_type): Update.
Change-Id: Ic4708ef99d43a8d99325ff91dee59b2eb706cb8f
In this context, we know that per_cu->cu will be set, as there is this
assertion:
gdb_assert (per_cu->cu != NULL)
So in order to remove the dwarf2_per_cu_data::dwarf2_per_objfile
reference in queue_and_load_all_dwo_tus, we can go through per_cu->cu.
This adds a reference to dwarf2_per_cu_data::cu, but it will get removed
eventually, in a subsequent patch.
gdb/ChangeLog:
* dwarf2/read.c (queue_and_load_all_dwo_tus): Access per_objfile
data through per_cu->cu.
Change-Id: Id4662828ac3c5bc93fe221df3c9bd9a36a8427ad
This allows removing references to the
dwarf2_per_cu_data::dwarf2_per_objfile field.
I am not too sure of the code flow here, but ultimately
open_and_init_dwo_file calls create_cus_hash_table, and passes it
per_cu->cu. create_cus_hash_table requires a dwarf2_cu to pass to
cutu_reader, as the "parent_cu".
The dwarf2_per_cu_data::cu link is only set when in a certain context.
It's not easy to convince myself in which situations it's safe to use
it. Instead, if a function is going to use a dwarf2_cu, I think it's
simpler if it takes that object directly. If it needs access to the
corresponding dwarf2_per_cu_data object, then it can used the
dwarf2_cu::per_cu field, which we know is always set.
This patch adds some references to dwarf2_per_cu_data::cu in the
cutu_reader context. In this context, we know this field will be set,
as it's cutu_reader that is responsible for instantiating the dwarf2_cu
and assigning the field.
gdb/ChangeLog:
* dwarf2/read.c (lookup_dwo_comp_unit): Change
dwarf2_per_cu_data parameter fo dwarf2_cu.
(lookup_dwo_type_unit): Likewise.
(read_cutu_die_from_dwo): Likewise.
(lookup_dwo_unit): Likewise.
(open_and_init_dwo_file): Likewise.
(lookup_dwo_cutu): Likewise.
(lookup_dwo_comp_unit): Likewise.
(lookup_dwo_type_unit): Likewise.
(cutu_reader::init_tu_and_read_dwo_dies): Update.
(cutu_reader::cutu_reader): Update.
Change-Id: I0406a715b0797963bde2bd86237f159cbece5839
