| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes some of the Ada code to simplify symbol searches. For
example, if a function is being looked for, the search is narrowed to
use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT. In one spot, a
search of the "struct" domain is removed, because Ada does not have a
tag domain.
|
|
This patch changes the DWARF reader to use the new symbol domains. It
also adjusts many bits of associated code to adapt to this change.
The non-DWARF readers are updated on a best-effort basis. This is
somewhat simpler since most of them only support C and C++. I have no
way to test a few of these.
I went back and forth a few times on how to handle the "tag"
situation. The basic problem is that C has a special namespace for
tags, which is separate from the type namespace. Other languages
don't do this. So, the question is, should a DW_TAG_structure_type
end up in the tag domain, or the type domain, or should it be
language-dependent?
I settled on making it language-dependent using a thought experiment.
Suppose there was a Rust compiler that only emitted nameless
DW_TAG_structure_type objects, and specified all structure type names
using DW_TAG_typedef. This DWARF would be correct, in that it
faithfully represents the source language -- but would not work with a
purely struct-domain implementation in gdb. Therefore gdb would be
wrong.
Now, this approach is a little tricky for C++, which uses tags but
also enters a typedef for them. I notice that some other readers --
like stabsread -- actually emit a typedef symbol as well. And, I
think this is a reasonable approach. It uses more memory, but it
makes the internals simpler. However, DWARF never did this for
whatever reason, and so in the interest of keeping the series slightly
shorter, I've left some C++-specific hacks in place here.
Note that this patch includes language_minimal as a language that uses
tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp,
which doesn't specify the language for a type unit. Arguably this
test case is wrong.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
|
|
This changes lookup_symbol and associated APIs to accept
domain_search_flags rather than a domain_enum.
Note that this introduces some new constants to Python and Guile. I
chose to break out the documentation patch for this, because the
internals here do not change until a later patch, and it seemed
simpler to patch the docs just once, rather than twice.
|
|
This changes quick_symbol_functions::lookup_global_symbol_language to
accept domain_search_flags rather than just a domain_enum, and fixes
up the fallout.
To avoid introducing any regressions, any code passing VAR_DOMAIN now
uses SEARCH_VFT.
That is, no visible changes should result from this patch. However,
it sets the stage to refine some searches later on.
|
|
This patch changes gdb to replace search_domain with
domain_search_flags everywhere. search_domain is removed.
|
|
A patch later in this series will change check_typedef to also look in
the type domain. This change by itself caused a regression, but one
that revealed some peculiar behavior.
The regression is in nullptr_t.exp, where examining a std::nullptr_t
will change from the correct:
typedef decltype(nullptr) std::nullptr_t;
to
typedef void std::nullptr_t;
Right now, the DWARF reader marks all unspecified types as stub types.
However, this interacts weirdly with check_typedef, which currently
does not try to resolve types -- only struct-domain objects.
My first attempt here was to fix this by changing void types not to be
stub types, as I didn't see what value that provided. However, this
caused another regression, because call_function_by_hand_dummy checks
for stub-ness:
if (values_type == NULL || values_type->is_stub ())
values_type = default_return_type;
I'm not really sure why it does this rather than check for
TYPE_CODE_VOID.
While looking into this, I found another oddity: the DWARF reader
correctly creates a type named 'decltype(nullptr)' when it seems a
DW_TAG_unspecified_type -- but it creates a symbol named "void"
instead.
This patch changes the DWARF reader to give the symbol the correct
name. This avoids the regression.
|
|
A DW_TAG_entry_point symbol inherits its extern/static property from
the enclosing subroutine. This is encoded in new_symbol -- but the
cooked indexer does not agree.
|
|
I noticed a couple of spots in dwarf/read.c:new_symbol that call
add_symbol_to_list. However, this function is generally written to
set list_to_add, and then have a single call to add_symbol_to_list at
the end. This patch cleans up this discrepancy.
Note that new_symbol is overlong and should probably be split up.
|
|
Testing this entire series pointed out that the cooked index scanner
disagrees with new_symbol about certain symbols. In particular,
new_symbol has this comment:
Ada and Fortran subprograms, whether marked external or
not, are always stored as a global symbol, because we want
This patch updates the scanner to match.
I don't know why the current code does not cause failures.
It's maybe worth noting that incremental CU expansion -- creating
symtabs directly from the index -- would eliminate this sort of bug.
|
|
A user found that gdb would not correctly print a field from an Ada
record using the scalar storage order feature. We tracked this down
to a combination of problems.
First, GCC did not emit DW_AT_endianity on the enumeration type.
DWARF does not specify this, but it is an obvious and harmless
extension. This was fixed in GCC recently:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.html
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd
Second, GDB did not handle this attribute on enumeration types. This
patch makes this change and adds a test case that will pass with the
patched GCC.
So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes
in, the test case in this patch can be updated to reflect that.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
In one spot, DW_OP_GNU_push_tls_address is handled differently from
DW_OP_form_tls_address. However, I think they should always be
treated identically.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in
favor of methods on struct symbol. More changes could be done here to
improve the design and make things safer, but I just wanted to do a
straightforward change to remove the macros for now.
Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
|
|
In the past, dwarf2_per_cu_data was allocated using malloc, so special
handling was needed for the vector used for symtab handling. We
changed this to use 'new' a while back, so this code can now be
greatly simplified.
Regression tested on x86-64 Fedora 38.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This rewrites GDB's .debug_names writer. It is now closer to the form
imagined in the DWARF spec. In particular, names are emitted exactly
as they appear in the original DWARF.
In order to make the reader work nicely, some extensions were needed.
These were all documented in an earlier patch. Note that in
particular this writer solves the "main name" problem by putting a
flag into the table.
GDB does not use the .debug_names hash table, so it also does not
write one. I consider this hash table to be essentially useless in
general, due to the name canonicalization problem -- while DWARF says
that writers should use the system demangling style, (1) this style
varies across systems, so it can't truly be relied on; and (2) at
least GCC and one other compiler don't actually follow this part of
the spec anyway.
It's important to note, though, that even if the hash was somehow
useful, GDB probably still would not use it -- a sorted list of names
is needed for completion and performs reasonably well for other
lookups, so a hash table is just overhead, IMO.
String emission is also simplified. There's no need in this writer to
ingest the contents of .debug_str.
A couple of tests are updated to reflect the fact that they now "fail"
because the tests don't include .debug_aranges in the .S file.
Arguably the .debug_names writer should also create this section; but
I did not implement that in this series, and there is a separate bug
about it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24820
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549
|
|
I don't know why gdb had the .debug_names augmentation string in two
separate places; this patch exports it in one spot, to be used in
another.
|
|
This rewrites the .debug_names reader to follow the spec.
Since it was first written, gdb's .debug_names writer has been
incorrect -- while the form of the section has been ok, the contents
have been very gdb-specific.
This patch fixes the reader side of this equation, rewriting the
reader to create a cooked index internally -- an important detail
because it allows for the deletion of a lot of code, and it means the
various readers will agree more often.
This reader checks for a new augmentation string. For the time being,
all other producers are ignored -- the old GDB ones because they are
wrong, and clang because it does not emit DW_IDX_parent. (If there
are any other producers, I'm unaware of them.)
While the new reader mostly runs in a worker thread, it does not try
to distribute its work. This could be done by partitioning the name
table. The parent computations could also be done in parallel after
all names have been read. I haven't attempted this.
Note that this patch temporarily regresses gdb.base/gdb-index-err.exp.
This test writes an index using gdb -- but at this particular stage,
gdb cannot read the indexes it creates. Rather than merge the patches
into a mega-patch, I've chosen to just accept this temporary
regression.
In v1 of this patch, I made the new reader more strict about requiring
.debug_aranges. In v2, I've backed this out and kept the previous
logic. This solved a few test failures, though it's arguably not the
right approach.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950
|
|
The handling of an empty hash table in the .debug_names reader is
slightly wrong.
Currently the code assumes there is always an array of hashes.
However, section 6.1.1.4.5 Hash Lookup Table says:
The optional hash lookup table immediately follows the list of
type signatures.
and then:
The hash lookup table is actually two separate arrays: an array of
buckets, followed immediately by an array of hashes.
My reading of this is that the hash table as a whole is optional, and
so the hashes will not exist in this case. (This also makes sense
because the hashes are not useful without the buckets anyway.)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950
|
|
I noticed that cooked_index_worker::start_reading isn't really needed.
This patch removes it, and also removes the SCOPED_EXIT, in favor of a
direct call.
|
|
This changes cooked_index_worker to be an abstract base class. The
base class implementation is moved to cooked-index.c, and a concrete
subclass is added to read.c.
This change is preparation for the new .debug_names reader, which will
supply its own concrete implementation of the worker.
|
|
The new .debug_names reader will work by creating a cooked index from
.debug_names. This patch updates cooked_index::maybe_write_index to
avoid writing the index in this case.
However, in order to do this in a clean way, the readers are changed
so that a nullptr result from index_for_writing means "cannot be
done", and then the error message is moved into write_dwarf_index
(where it historically lived).
|
|
This moves the declaration of cooked_index_functions to
cooked-index.h. This makes it visible for use by the rewritten
.debug_names reader, and it also lets us move the implementation of
make_quick_functions into cooked-index.c, where it really belongs.
|
|
This adds a new 'lang' member to cooked_index_entry. This holds the
language of the symbol. This is primarily useful for the new
.debug_names reader, which will not scan the CUs for languages up
front.
This also changes cooked_index_shard::add to return a non-const
pointer. This doesn't impact the current code, but is needed for the
new reader.
|
|
I noticed that cooked_index_flag::IS_ENUM_CLASS is not needed. This
patch removes it.
|
|
While working on the previous patch, I saw that the handling of
quick-function installation could be unified
dwarf2_initialize_objfile. In particular, at the end of the function,
if there is an index table, then it can be used to create the quick
function object.
This cleanup will be useful when rewriting the .debug_names reader.
|
|
The new .debug_names reader will reuse the background reading
infrastructure of the cooked index code. In order to share the
handling of 'maint set dwarf synchronous' -- and to avoid having to
export this global -- this patch refactors this to be handled directly
in dwarf2_initialize_objfile.
|
|
When I run the struct-with-sig-2.exp test with the .debug_names-using
target board, I see a gdb crash. This happens because the reader
throws an exception without calling finalize_all_units. This causes
an assertion failure later because the number of CUs and TUs doesn't
match.
The fix is to clear 'all_units' on failure.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
It occurred to me that there is no reason for addrmap_fixed::set_entry
to exist. This patch removes it and removes the abstract virtual
function from the base class. This then required a few minor changes
in the DWARF reader. I consider this a type-safety improvement.
Tested by rebuilding.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
Currently cooked_index entry creation is either:
- done immediately if the parent_entry is known, or
- deferred if the parent_entry is not yet known, and done later while
resolving the deferred entries.
Instead, create all cooked_index entries immediately, and keep track of which
entries have a parent_entry that needs resolving later using the new
IS_PARENT_DEFERRED flag.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make cooked_index_entry::parent_entry private, and add member functions to
access it.
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make cooked_index_storage::add and cooked_index_entry::add return a
"cooked_index_entry *" instead of a "const cooked_index_entry *".
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Simon pointed out that my recent change to the DWO code caused a
failure in ASAN testing.
The bug here was I updated the code to use a different search type in
the hash table; but then did not change the search code to use
htab_find_slot_with_hash.
Note that this bug would not be possible with my type-safe hash table
series, hint, hint.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
A user pointed out that the recent background DWARF reader series
broke the build when --disable-threading is in use. This patch fixes
the problem. I am checking it in.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223
|
|
dwarf2_base_index_functions::find_per_cu is documented as using an
unrelocated address. This patch changes the interface to use the
unrelocated_addr type, just to be a bit more type-safe.
Regression tested on x86-64 Fedora 38.
|
|
dwarf2_has_info and dwarf2_initialize_objfile are only separate
because the DWARF reader implemented lazy psymtab reading. However,
now that this is gone, we can simplify the public DWARF API again.
|
|
This patch rearranges the DWARF reader so that more work is done in
the background. This is PR symtab/29942.
The idea here is that there is only a small amount of work that must
be done on the main thread when scanning DWARF -- before the main
scan, the only part is mapping the section data.
Currently, the DWARF reader uses the quick_symbol_functions "lazy"
functionality to defer even starting to read. This patch instead
changes the reader to start reading immediately, but doing more in
worker tasks.
Before this patch, "file" on my machine:
(gdb) file /tmp/gdb
2023-10-23 12:29:56.885 - command started
Reading symbols from /tmp/gdb...
2023-10-23 12:29:58.047 - command finished
Command execution time: 5.867228 (cpu), 1.162444 (wall)
After the patch, more work is done in the background and so this takes
a bit less time:
(gdb) file /tmp/gdb
2023-10-23 13:25:51.391 - command started
Reading symbols from /tmp/gdb...
2023-10-23 13:25:51.712 - command finished
Command execution time: 1.894500 (cpu), 0.320306 (wall)
I think this could be further sped up by using the shared library load
map to avoid objfile loops like the one in expand_symtab_containing_pc
-- it seems like the correct objfile could be chosen more directly.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174
|
|
This changes the cooked index code to wait for threads in its
public-facing API. That is, the waits are done in cooked_index now,
and never in the cooked_index_shard. Centralizing this decision makes
it easier to wait for other events here as well.
|
|
For testing, it's sometimes convenient to be able to request that
DWARF reading be done synchronously. This patch adds a new "maint"
setting for this purpose.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This moves cooked_index_storage to cooked-index.h. This is needed by
a subsequent patch.
|
|
When DWARF reading is done in the background,
read_addrmap_from_aranges will be called from a worker thread.
Because warnings can't be emitted from these threads, this patch adds
a new deferred_warnings parameter to the function, letting the caller
control exactly how the warnings are emitted.
|
|
This patch changes the way complaint works in a background thread.
The new approach requires installing a complaint interceptor in each
worker, and then the resulting complaints are treated as one of the
results of the computation. This change is needed for a subsequent
patch, where installing a complaint interceptor around a parallel-for
is no longer a viable approach.
|
|
This changes gdb to ensure that gdb's BFD cache is guarded by a lock.
This avoids any races when multiple threads might open a BFD (and thus
use the BFD cache) at the same time.
Currently, this change is not needed because the the main thread waits
for some DWARF scanning to be completed before returning. The only
locking that's required is when opening DWO files, and there's a local
lock to this end in dwarf2/read.c.
However, in the coming patches, the DWARF reader will begin its work
earlier, in the background. This means there is the potential for the
DWARF reader and other code on the main thread to both attempt to open
BFDs at the same time.
|
|
This adds a couple of calls to bfd_cache_close at points where a BFD
isn't actively needed by gdb. Normally at these points, all the
needed section data is already mapped, so we can simply close the file
descriptor. This is harmless at worst, because if this is needed
after all, the BFD file descriptor cache will reopen it.
|
|
This changes the DWZ code to pre-read the section data and somewhat
simplify the DWZ API. This makes it easier to add the bfd_cache_close
call to the new dwarf2_read_dwz_file function -- after this is done,
there shouldn't be a reason to keep the BFD's file descriptor open.
|
|
The DWO code in the DWARF reader currently uses objfile::intern. This
accesses a shared data structure and so would be racy when used from
multiple threads. I don't believe this can happen right now, but
background reading could provoke this, and in any case it's better to
avoid this, just to be sure.
This patch changes this code to just use a std::string. A new type is
introduced to do hash table lookups, to avoid unnecessary copies.
|
|
This commit adds a mechanism for GDB to detect the linetable opcode
DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
that a certain instruction marks the point where the frame is destroyed.
While the standard allows for multiple points marked with epilogue_begin
in the same function, for performance reasons, the function that
searches for the epilogue address will only find the last address that
sets this flag for a given block.
This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
use the epilogue begin directly, and only if an epilogue can't be found
will it attempt heuristics based on the current instruction.
Finally, this commit also changes the dwarf assembler to be able to emit
epilogue-begin instructions, to make it easier to test this patch
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fortran provides additional entry points for subroutines and functions.
These entry points may use only a subset (or a different set) of the
parameters of the original subroutine. The entry points may be described
via the DWARF tag DW_TAG_entry_point.
This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
Currently, between ifx/ifort/gfortran, only ifort is actually emitting
this tag. Both, ifx and gfortran use the DW_TAG_subprogram tag as
workaround/alternative. Thus, this patch really only adds more ifort
support. Even so, some of the attached tests still fail for ifort, due
to some wrong line info generated for the entry points in ifort.
After this patch it is possible to set a breakpoint in gdb with the
ifort compiled example at the entry points 'foo' and 'foobar', which was not
possible before.
As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
which uses some underlying c compiled code and adds some Fortran style DWARF
to it emitting the DW_TAG_entry_point. Before this patch it was not
possible to actually define breakpoint at the entry point tags.
For gfortran there actually exists a bug on bugzilla, asking for the use
of DW_TAG_entry_point over DW_TAG_subprogram:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134
This patch was originally posted here
https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html
but its review/pinging got lost after a while. I reworked it to fit the
current GDB.
Co-authored-by: Bernhard Heckel <bernhard.heckel@intel.com>
Co-authored-by: Tim Wiederhake <tim.wiederhake@intel.com>
Approved-by: Tom Tromey <tom@tromey.com>
|
|
In dwarf2_get_pc_bounds we were writing unchecked to *lowpc. This
commit adds a gdb_assert to first check that lowpc != nullptr.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
This commit is in preparation of the next commit. There, we will add
a second variation to retrieve the pc bounds for DIEs tagged with
DW_TAG_entry_point. Instead of dwarf_get_pc_bounds_ranges_or_highlow_pc
we will call a separate method for entry points. As the validity checks
at the endo f dwarf2_get_pc_bounds are the same for both variants,
we introduced the new dwarf_get_pc_bounds_ranges_or_highlow_pc method,
outsourcing part of dwarf2_get_pc_bounds.
This commit should have no functional impact on GDB.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
PR28987 notes that optimized code sometimes shows the wrong
value of variables at the entry point of a function, if some
code was optimized away and the variable has multiple values
stored in the debug info for this location.
In this example:
```
void foo()
{
int l_3 = 5, i = 0;
for (; i < 8; i++)
;
test(l_3, i);
}
```
When compiled with optimization, the entry point of foo is at
the test() function call, since everything else is optimized
away.
The debug info of i looks like this:
```
(gdb) info address i
Symbol "i" is multi-location:
Base address 0x140001600 Range 0x13fd41600-0x13fd41600: the constant 0
Range 0x13fd41600-0x13fd41600: the constant 1
Range 0x13fd41600-0x13fd41600: the constant 2
Range 0x13fd41600-0x13fd41600: the constant 3
Range 0x13fd41600-0x13fd41600: the constant 4
Range 0x13fd41600-0x13fd41600: the constant 5
Range 0x13fd41600-0x13fd41600: the constant 6
Range 0x13fd41600-0x13fd41600: the constant 7
Range 0x13fd41600-0x13fd4160f: the constant 8
(gdb) p i
$1 = 0
```
Currently, when at the entry point of a function, it will
always show the initial value (here 0), while the user would
expect the last value (here 8).
This logic was introduced for showing the entry-values of
function arguments if they are available, but for some
reason this was added for non-entry-values as well.
One of the tests of amd64-entry-value.exp shows the same
problem for function arguments, if you "break stacktest"
in the following example, you stop at this line:
```
124 static void __attribute__((noinline, noclone))
125 stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2,
126 double d1, double d2, double d3, double d4, double d5, double d6,
127 double d7, double d8, double d9, double da)
128 {
129 s1 = 3;
130 s2 = 4;
131 d9 = 3.5;
132 da = 4.5;
133 -> e (v, v);
134 asm ("breakhere_stacktest:");
135 e (v, v);
136 }
```
But `bt` still shows the entry values:
```
s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5
```
I've fixed this by only using the initial values when
explicitely looking for entry values.
Now the local variable of the first example is as expected:
```
(gdb) p i
$1 = 8
```
And the test of amd64-entry-value.exp shows the expected
current and entry values of the function arguments:
```
s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
