| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This teaches cooked_index_entry::full_name that "::" is the separator
for Fortran. I don't know enough Fortran to write a test case for
this. However, a different series I am working on has a regression if
this patch is not applied.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that if you hack some clean_restart calls into
paramless.exp, the test will fail. That is, the test currently relies
on the desired CUs already being expanded when trying to set a
breakpoint -- which is clearly a bug, the CU expansion state should
not affect "break".
I tracked this down to incorrect construction of a lookup_name_info in
cooked_index_functions::expand_symtabs_matching.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32510
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Heap-allocated dwo_file objects, stored in dwarf2_per_bfd::dwo_files,
are never freed. They are created in one of the
create_dwo_unit_in_dwp_* or lookup_dwo_cutu functions. I confirmed this
by running:
$ make check TESTS="gdb.cp/anon-ns.exp" RUNTESTFLAGS="--target_board=fission-dwp"
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.cp/anon-ns/anon-ns -ex "p main" -ex "file" -batch
... and checking the ASan leak report. I also debugged this invocation
of GDB, placed a breakpoint on ~dwo_file, and didn't see any hit.
Change the dwo_file set to hold dwo_file_up objects. When the
dwarf2_per_bfd object gets destroyed, dwo_file objects will
automatically get destroyed. With this change, I see the related leaks
disappear in the ASan leak report, and my ~dwo_file breakpoint gets hit
when debugging GDB.
Change-Id: Icb38539c3f9e553f3625c625a00fc63dd6e9f3c5
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change the dwarf2_per_bfd::dwo_files htab to a gdb::unordered_set.
No behavior change expected, except maybe the failure case in
lookup_dwo_cutu. If open_and_init_dwo_file returns nullptr, the
previous code would leave the slot value empty (nullptr). Is this
legit? With the new hash table, the only thing we can do really is not
attempt to insert the nullptr value.
Change-Id: I63992f388b1197e696ded4ea483634e8ae67fce4
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change a few occurences of htabs holding `dwo_unit *` values, using
their signature as identity, to gdb::unordered_set.
allocate_dwo_unit_table and allocate_dwp_loaded_cutus_table appeared to
create hash tables with identical behavior, so they both use the same
set type now.
The only expected change in behavior is that when there are multiple
units with the same signature, we will now keep the unit previously in
the set, rather than overwriting it. But this seems ok, as it's a case
of bad DWARF.
Also, in the complaint in create_debug_type_hash_table, I think we
previously erroneously printed the same sect_off twice.
Change-Id: I57739977735ee1fd5c7b754107f5624f0621baa5
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change-Id: I40679fbe32a8a1a9cced085532c83f06affc294c
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In create_cus_hash_table, we can get the section and hash table from the
dwo_file directly.
In create_debug_type_hash_table, we can get the hash table from the
dwo_file directly - the section varies.
Change-Id: I1d5ef49df98fe2620e12b83484b28cd7398f24ae
Approved-By: Tom Tromey <tom@tromey.com>
|
|
die_reader_specs is a relic of some past design, today it only serves as
(useless) a base class for cutu_reader. Remove it and move all its
fields to cutu_reader.
Change-Id: I5d55018eb8c6e0b828ef5d2f6d09b2047d1a5912
Approved-By: Tom Tromey <tom@tromey.com>
|
|
We can use `cu->per_objfile` instead of passing down a
dwarf2_per_objfile explicitly.
Change-Id: Ie1fd93d9e7a74d09b857f1f0909d7441b79ed893
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It seems like the lh_cu variable is not necessary, we can just use
this_cu.
Change-Id: Ic2ed6ee82faf1fb5d340cd92dc8ef15434b20cb8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This creates a new file, dwarf2/parent-map.c, to hold some code
related to parent maps. This helps shrink read.c a bit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the .debug_names reader to dump the contents of the
index. This follows what the cooked index does, and also fixes a
couple of test failures when run with the debug-names board:
forward-spec-inter-cu.exp and backward-spec-inter-cu.exp.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
It is always known at construction time whether a dwarf2_per_cu is
built to represent a unit from a dwz file or not, so pass that
information through the constructor.
Change-Id: I278c1894ed606451aad02e830085190bb724c473
Approved-By: Tom Tromey <tom@tromey.com>
|
|
dwarf2_get_dwz_file looks more or less like a simple getter of
dwarf2_per_bfd::dwz_file, so make it into a method.
I typically avoid the `get_` prefix for getters, but that would conflict
with the field name here.
Change-Id: Idd0d5b1bd3813babf438b20aac514b19c77cfc18
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that create_cu_from_index_list is only used in
read-gdb-index.c, so I started by moving it there. But given that this
function is use at only one spot and doesn't do much, I opted to inline
its code in the caller instead.
Change-Id: Iebe0dc20d345fa70a2f11aa9ff1a04fe26a31407
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that cooked-index.h still refers to a vector of parent maps,
but the code itself actually uses a parent_map here.
|
|
I think debug-names-tu.exp.tcl only passes by accident -- the type
unit does not have a language, which gdb essentially requires.
This isn't noticeable right now because the type unit in question is
expanded in one phase and then the symbol found in another. However,
I'm working on a series that would regress this.
This patch partially fixes the problem by correcting the test case,
adding the language to the TU.
Hoewver, it then goes a bit further and arranges for this information
not to be written to .debug_names. Whether or not a type should be
considered "static" seems like something that is purely internal to
gdb, so this patch has the entry-creation function apply the
appropriate transform.
It also may make sense to change the "debug_names" proc in the test
suite to process attributes more like the ordinary "cu" proc does.
|
|
The parameter `abfd` is always the same as `this->obfd`, there is no
need to pass it as a parameter.
Change-Id: If7ad58ad4efdf6b070cbf2b8a73436bd8b452fa6
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This scratches an itch I had for a while. I don't know why this struct
type has "data" in its name. Others like "dwarf2_per_objfile" and
"dwarf2_per_bfd" don't. The primary job of a structure is to hold data,
there's no need to specify it. It also makes the name a bit shorter,
which is always nice.
Rename related types too.
Change-Id: Ifb63195ff105809fc15b502f639c0bb4d18a675e
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
I noticed we quite often use:
bfd_get_filename (per_bfd->obfd)
Add a shortcut for that.
Change-Id: I4e33925a481fd44088386510b01936d38e1d7d38
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I noticed a
// namespace selftests
comment, which doesn't follow our comment formatting convention. I did
a find & replace to fix all the offenders.
Change-Id: Idf8fe9833caf1c3d99e15330db000e4bab4ec66c
|
|
Commit 2f0521c0d6f6 ("gdb/dwarf: fix signature_type created with nullptr
section") added some asserts in the dwarf2_per_cu_data constructor to
verify that the passed dwarf2_per_bfd and dwarf2_section_info are not
nullptr. However, the dummy dwarf2_per_cu_data objects created in the
dwarf2_find_containing_comp_unit selftests are passed nullptr for those
parameters.
I prefer to keep the asserts in place, as protection for the non-test
code and as self documentation, so fix this by passing some dummy
pointers in the test.
Change-Id: Ic7cdc1b976f7506041b651222234eefc998e473a
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
Most of the time, the length of a unit is known when constructing a
dwarf2_per_cu_data or signatured_type. Add a construtor parameter for
it. In the few cases where it isn't, pass 0, which leaves it unset.
Change-Id: I0c8b9683164d3e3f3823ed995f71689a4d17fd96
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
On x86_64-linux, with gcc 7.5.0 I ran into a build breaker:
...
gdb/dwarf2/read.c: In function ‘void read_comp_units_from_section()’:
gdb/dwarf2/read.c:4297:31: error: unused variable ‘sig_type_it’ \
[-Werror=unused-variable]
auto [sig_type_it, inserted] = sig_types.emplace (sig_ptr);
^
...
Fix this by dropping the unused variable.
Tested on x86_64-linux, by completing a build.
|
|
Commit c44ab627b02 ("gdb/dwarf: pass section to dwarf2_per_cu_data
constructor") introduced a regression when using dwp. It can be
reproduced with:
$ make check TESTS="gdb.base/ptype-offsets.exp" RUNTESTFLAGS="--target_board=fission-dwp"
Then, to investigate:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets -ex 'ptype int'
Reading symbols from testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3195:38: runtime error: member call on null pointer of type 'struct dwarf2_section_info'
Commit c44ab627b02 removed the assignment of signatured_type::section
(dwarf2_per_cu_data::section, really) in
fill_in_sig_entry_from_dwo_entry with the justification that the section
was already set when constructing the signatured_type. Well, that was
true except for one spot in lookup_dwp_signatured_type which passes a
nullptr section to add_type_unit.
Fix that by passing the section to add_type_unit in that one spot. This
is the same section that would have been set by
fill_in_sig_entry_from_dwo_entry before.
Add some asserts in the dwarf2_per_cu_data constructor to verity that
the passed dwarf2_per_bfd and dwarf2_section_info are non-nullptr.
Change-Id: If27dae6b4727957c96defc058c7e4be31472005b
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32739
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I'd like to add these asserts in dwarf2_per_cu_data's constructor:
gdb_assert (per_bfd != nullptr);
gdb_assert (section != nullptr);
However, these dummy instances of signatured_type, used as hash table
lookup keys, are in the way:
signatured_type find_sig_entry (nullptr, nullptr, sect_offset {}, sig);
This motivated me to convert the dwarf2_per_bfd::signatured_types hash
table to a gdb::unordered_set. This allows finding an entry by simply
passing the signature (an integer) and removes the need to create dummy
signatured_type objects.
There is one small unfortunate pessimization:
lookup_dwo_signatured_type, for instance, does a lookup by signature to
find an existing signatured_type. If not found, it adds a new one by
calling add_type_unit. The current code passes down the slot where to
put the new element, avoiding an extra hash when inserting the new
signatured_type. With the new code, I don't see a way to do that. This
is probably negligible, but it bugs me. If we used a map of signature
-> signatured_type, I would see a way, but then it would waste space.
I see one change in behavior, that is not really important IMO. In
read_comp_units_from_section, if duplicate signature type entries are
detected, the code prior to this patch overwrites the existing
signatured_type in the hash table with the new one. With this patch,
the existing signatured_type is kept: the call to emplace does not
insert the value if an existing equal value exists.
Other than that, no behavior change expected.
Change-Id: I0bef1b49cc63dbdf4e32fa9d4ea37f83025efc3e
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I identified the following functions that currently take a
dwarf2_per_objfile, but could take a less specific dwarf2_per_bfd.
- try_open_dwop_file
- open_dwo_file
- open_dwp_file
The uses of the per-objfile object in try_open_dwop_file can be replaced
with equivalent per-bfd ones.
Change-Id: Ia31fa0b988375e86a715ee863d4ec3c572ce89c0
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I found a few spots where the existing dwz_file::filename method could
be used.
Change-Id: I0522b1e3abbfac2f392f9ec777c37b242ee236d8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
All users of these typedefs use them inside a gdb::function_view. Move
the gdb::function_view in the typedefs themselves. This shortens the
types in function signatures and helps with readability, IMO.
Rename them to remove the `_ftype` suffix: this suffix is not as
relevant in C++ as it was in C. With function_view, the caller can pass
more than just a simple "function". Anyway, I think it's clearer to
name them after the role the callback has (listener, matcher, etc).
Adjust some related comments.
Change-Id: Iaf9f8ede68b51ea9e4d954792e8eb90def8659a6
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Initialize fields of tu_stats to 0, remove the explicit default
initialization of dwarf2_per_bfd::tu_stats.
Change-Id: I98b2d5c4171291a3df2569466559174fb7cf32b6
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This include is reported as unused by clangd.
Change-Id: I95b73f85607537551ef54e46551197d1371d621b
|
|
I noticed a spot in dwarf2/index-write.c that was mis-formatted. This
fixes it.
|
|
Right now, cooked_index_functions::expand_symtabs_matching computes
the language for each component of a split name, using the language of
the corresponding entry.
Instead, I think that we want to do all the comparisons using the
final entry's language. I don't think there's a way to trigger bad
behavior here right now, but with another series I'm working on, we
end up with some entries whose language can't reliably be determined;
and in this case using the final entry's language avoids issues.
I suspect we could also dispense with the per-segment name-matcher
lookup as well.
|
|
This changes the various producer-checking functions to be methods on
dwarf2_cu. It adds a few new caching members as well -- every one
that could reasonably be done this way has been converted, with the
only exception being a gdbarch hook.
Note the new asserts in the accessors. Without the earlier
prepare_one_comp_unit change, these could trigger in some modes.
|
|
This changes prepare_one_comp_unit to be a private method of
cutu_reader. This should make it somewhat simpler to reason about.
|
|
Currently, prepare_one_comp_unit is called somewhat haphazardly: it is
mostly called when a CU is read, but some places manage to instantiate
a cutu_reader* without calling it, and some code (e.g.,
read_file_scope) calls it without really needing to.
Aside from contributing to the general confusion around CU reading,
this doesn't really cause problems in the current tree. However, it
is possible for the DWARF reader to check the CU's producer before it
is ever set -- which is certainly unintended.
|
|
This moves the producer_is_realview to producer.c.
|
|
In dwarf2/read.c:new_symbol, DW_TAG_namelist is listed in the same
part of the "switch" as other tags. However, it effectively shares no
code with these. This patch splits it into its own case.
Longer term I think new_symbol should be split up drastically.
|
|
I was trying to get an understanding of which CUs were expanded when,
and how much time it was taking. I wrote this patch to add some logging
related to that, and I think it would be useful to have upstream, to
better understand performance problems related to over-eager CU
expansion, for example.
- add DWARF_READ_SCOPED_DEBUG_START_END
- use it in process_queue, to wrap the related expansion messages
together
- add a message in maybe_queue_comp_unit when enqueuing a comp unit
- add timing information to messages in process_queue, indicating how
much time it took to expand a given symtab
- count the number of expansions done in a single call to process_queue
[dwarf-read] process_queue: start: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xc
[dwarf-read] maybe_queue_comp_unit: Queuing CU for expansion: section offset = 0x38b, queue size = 2
[dwarf-read] process_queue: Done expanding CU at offset 0xc, took 0.001s
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x38b
[dwarf-read] process_queue: Done expanding CU at offset 0x38b, took 0.000s
[dwarf-read] process_queue: Done expanding 2 symtabs.
[dwarf-read] process_queue: end: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...
Change-Id: I5237d50e0c1d06be33ea83a9120b5fe1cf7ab8c2
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This makes it more obvious that all created signatured_type objects have
this flag set.
Also, remove an unnecessary assignment in create_cus_hash_table: when
constructing the dwarf2_per_cu_data object, is_debug_types is already
initialized to 0/false.
Change-Id: I6d28b17ac77edc040172254f6970d05ebc4a47f4
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Same as the previous patch, but for the containing section.
Change-Id: I469147cce21525d61b3cf6edd9a9f4b12027c176
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Similar to the previous patch, but for the offset within the containing
section.
Change-Id: I1d76e1f88002bca924e0b12fd78c7ea49d36c0ec
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Pass a dwarf2_per_bfd to the constructor of dwarf2_per_cu_data and set
the per_bfd field there. All "real" instantiations of
dwarf2_per_cu_data must have a valid, non-nullptr dwarf2_per_bfd
backlink, this makes it a bit more obvious. The instantiations of
dwarf2_per_cu_data that receive a nullptr dwarf2_per_bfd are the ones
used to do hash map lookups and the ones used in selftests.
Remove an unnecessary assignment of per_bfd in
fill_in_sig_entry_from_dwo_entry: the per_bfd field is already set when
the signatured_type object is constructor (before that, it was set in
allocate_signatured_type).
Change-Id: Ifeebe55fdb1bc2de4de9c852033fafe8abdfde8a
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that the following functions accept a "dwarf2_per_objfile",
but they can actually accept a less specific "dwarf2_per_bfd". This
makes it more obvious that the work they do is per BFD and not per
objfile.
- add_type_unit
- lookup_dwo_file_slot
- create_dwo_unit_in_dwp_v1
- create_dwp_v2_or_v5_section
- create_dwo_unit_in_dwp_v2
- create_dwo_unit_in_dwp_v5
- lookup_dwo_unit_in_dwp
Change-Id: I200cd77850ce0ffa29fc1b9d924056fdce2559f8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
No behavior changes expected.
Change-Id: I16ff6c67058362c65cc8edb05d1948e48be6b2e1
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change-Id: I9a6bf27b72f7efb1cc4cea5345db14969e794bdb
|
|
Change-Id: I420280721cb734a2e061743309bf9b25d2179f8f
|
|
The recent .debug_names patches caused the writer to emit
DW_FORM_data4. Unfortunately the reader did not handle this form.
This patch updates the reader to handle a few DW_FORM_data* forms.
The complaint that is there went unnoticed -- I only found this when
debugging a failure in another series. More evidence, IMO, that
complaints should be removed.
I think the reason the failure itself went unnoticed is that the
symbol table code in gdb often works by accident, and in particular in
small programs like the ones in the test suite, it's often the case
that a CU will be expanded for some other reason, causing the test to
pass without really touching the index code. The aforementioned
series is aimed at fixing this.
It would probably be good to unify the abbrev/form code to some
degree, but it's mildly a pain as some forms don't make sense here and
because we recently discovered other issues with gdb's DW_FORM_data*
handling.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Throughout gdb/dwarf2, use `*_up` typedefs. Add a few missing typedefs,
and move some so they are, ideally, just after the corresponding class.
Change-Id: Iab5cd8fc2e9989d4bd8d4868586703c2312f254f
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Rename them to include "worker" in the name. Otherwise, it's easy to be
confused and think that they are sub-classes of "cooked_index".
Change-Id: I625ef076f9485f3873db530493f60a53d02c1991
Approved-By: Tom Tromey <tom@tromey.com>
|
