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.
Given that GDB now requires a C++17, replace all uses of
gdb::string_view with std::string_view.
This change has mostly been done automatically:
- gdb::string_view -> std::string_view
- #include "gdbsupport/gdb_string_view.h" -> #include <string_view>
One things which got brought up during review is that gdb::stging_view
does support being built from "nullptr" while std::sting_view does not.
Two places are manually adjusted to account for this difference:
gdb/tui/tui-io.c:tui_getc_1 and
gdbsupport/format.h:format_piece::format_piece.
The above automatic change transformed
"gdb::to_string (const gdb::string_view &)" into
"gdb::to_string (const std::string_view &)". The various direct users
of this function are now explicitly including
"gdbsupport/gdb_string_view.h". A later patch will remove the users of
gdb::to_string.
The implementation and tests of gdb::string_view are unchanged, they will
be removed in a following patch.
Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
This commit merges the code that looks for and loads the separate
debug symbol files from coffread.c and elfread.c. The factored out
code is moved into a new objfile::find_and_add_separate_symbol_file()
method.
For the elfread.c path there should be no user visible changes after
this commit.
For the coffread.c path GDB will now attempt to perform a debuginfod
lookup for the missing debug information, assuming that GDB can find a
build-id in the COFF file.
I don't know if COFF files can include a build-id, but I the existing
coffread.c code already includes a call to
find_separate_debug_file_by_build-id, so I know that it is at least OK
for GDB to ask a COFF file for a build-id. If the COFF file doesn't
include a build-id then the debuginfod lookup code will not trigger
and the new code is harmless.
If the COFF file does include a build-id, then we're going to end up
asking debuginfod for the debug file. As build-ids should be unique,
this should be harmless, even if debuginfod doesn't contain any
suitable debug data, it just costs us one debuginfod lookup, so I'm
not too worried about this for now.
As with the previous commit, I've done some minimal testing using the
mingw toolchain on a Linux machine, GDB seems to still access the
split debug information just fine.
Approved-By: Tom Tromey <tom@tromey.com>
This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc). I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.
Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This commit fixes a bug mentioned by Florian Weimer during the
libpthread/ld.so load order discussion from 2021. Florian provided
instructions for reproducing the bug here:
https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html
That particular test does some interesting things involving forks,
threads, and thread local storage. Fortunately, none of that is
needed to reproduce the problem.
I've made a new test case (which is now found in a separate commit)
contained in the files gdb.base/add-symbol-file-attach.{c,exp}. The
.c file is fairly simple as is the recipe for reproducing the problem.
After separately starting the test case and noting the process id,
start gdb (w/ no arguments), and do the following to reproduce the
assertion failure - for this run, the process id of the separately
started add-symbol-file-attach process is 4103218:
(gdb) add-symbol-file add-symbol-file-attach
add symbol table from file "add-symbol-file-attach"
(y or n) y
Reading symbols from add-symbol-file-attach...
(gdb) attach 4103218
Attaching to process 4103218
Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f502130bf27 in pause () from /lib64/libc.so.6
(gdb) p foo
symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*,
const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The add-symbol-file command causes the symbols to be loaded without
the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being
set. This, in turn, causes the "maybe_copied" flag to be set for
the global symbol (named "foo" in the provided test case).
The attach command will cause another objfile to be created, but
it will reuse the symtabs from the objfile created by add-symbol-file,
leading to a situation in which the OBJFILE_MAINLINE flag will be set
for the new (attach-created) objfile, however the "maybe_copied"
flag will still be set for the global symbol. Had it been loaded
anew, this flag would not be set due to OBJFILE_MAINLINE being set
for the objfile.
At present, minimal_symbol::value_address looks like this:
CORE_ADDR
minimal_symbol::value_address (objfile *objfile) const
{
if (this->maybe_copied (objfile))
return get_msymbol_address (objfile, this);
else
return (CORE_ADDR (this->unrelocated_address ())
+ objfile->section_offsets[this->section_index ()]);
}
So, we can now see the problem: When the "maybe_copied" flag is set,
get_msymbol_address() will be called. However, get_msymbol_address()
assumes that it won't be called with the OBF_MAINLINE flag set for
the objfile in question. It, in fact, contains an assert() which
makes sure that this is the case:
gdb_assert ((objf->flags & OBJF_MAINLINE) == 0);
(If this assert is removed, then get_msymbol_address() recurses
infinitely for the case under consideration.)
So, the problem here is that the maybe_copied flag is set for the
symbol AND the OBJF_MAINLINE flag is set for the objfile. As noted
earlier, this happens due to add-symbol-file being used; this causes
the maybe_copied flag to be set. Later, when the attach is performed,
OBJF_MAINLINE will be set for that objfile, leading to this
unfortunate situation.
My first cut at a solution involved adjusting the
MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the
method noted above) to include a test of the OBJFILE_MAINLINE flag.
However, Simon Marchi, in his review of my patch, suggested a better
solution. Simon observed that the 'maybe_copied' flag is (was, after
this commit) being set/initialized in record_minimal_symbol() using
using the objfile in the context in which the symbol was created.
Simon further observed:
Today, a single copy is created, as symtabs are shared between
objfiles. This means that everything that we store into a symbol
must be independent of any objfile. However, the value of the
maybe_copied field is dependent on the objfile in the context of
which the symbol was created. Meaning that when the symbol is
re-used in the context of another objfile, the maybe_copied value is
not right in the context of that objfile.
So I think it means there isn't a single "is this symbol maybe
copied" value, but instead "is this symbol maybe copied, in the
context of this given objfile". And the answer is yes or no,
depending on whether the objfile is mainline. So maybe_copied
should become a method that takes an objfile and returns an answer
based on that.
Simon's full review can be found here:
https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html
Simon also provided a patch which implements this suggestion. The
current patch is mostly his work, though I did make some adjustments
during a rebase in addition to making some changes to account for a
concern from Tom Tromey.
During his review of the v3 series, Tom noted, "The old approach was
specific to ELF, while the new approach will be used by any object
format." Tom further observed, "...it seems like it could result in an
incorrect evaluation in some scenario." This seemed plausible to me,
so I introduced the flag 'object_format_has_copy_relocs' to struct
objfile. It is set at the end of elf_symfile_read() in elfread.c.
The minimal_symbol::maybe_copied method tests this new flag, forcing
this method to return false when the flag is not set. If we find that
other object file formats use the same copy reloc mechanism as ELF,
then 'object_format_has_copy_relocs' should be set for objfiles using
those formats.
Lastly, I'll note that this is a strange use case. It's far more
common to either let gdb figure out which file to load by itself when
attaching, i.e.
(gdb) attach 4104360
Attaching to process 4104360
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
(gdb) p foo
$1 = 42
...or to use the "file" command prior to the attach, like this:
(gdb) file add-symbol-file-attach
Reading symbols from add-symbol-file-attach...
(gdb) attach 4104360
Attaching to program: /tmp/add-symbol-file-attach, process 4104360
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
Both of these more common scenarios work perfectly fine; using
"add-symbol-file" to load the program to which you will attach
isn't recommended as a normal use case. That said, it's bad for
gdb to assert, hence this fix.
Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Approved-by: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
After the commit:
commit 6647f05df0
Date: Tue Jan 24 18:13:38 2023 +0100
gdb: defer warnings when loading separate debug files
It was pointed out[1] that the warnings being deferred and then later
emitted lacked styling. The warnings lacked styling before the above
commit, but it was suggested that the filenames in these warnings
should be styled, and this commit does this.
There were a couple of previous attempts[2][3][4] to solve this
problem, but these all tried to extend the mechanism introduced in the
above commit, the deferred warnings were placed directly into a
std::vector, but now we tried to, when appropriate, style these
warnings. The review feedback that this approach looked too complex.
So instead, this revision adds a new helper class 'deferred_warnings'
which can be used to collect a set of deferred warnings, and then emit
these deferred warnings later, if needed. This helper class hides the
complexity, so at the point the deferred warning is created no extra
logic is required.
The deferred_warnings class will style the deferred warnings only if
gdb_stderr supports styling. GDB's warnings are sent to gdb_stderr,
so this should ensure we only style when expected.
There was also review feedback[5] that all of the warnings should be
bundled into a single string_file, this has not been done. I feel
pretty strongly that separate warnings should be emitted using
separate "warning" calls. If we do end up with multiple warnings in
this case they aren't really related, one will be about looking up
debug via .gnu_debuglink, while the other will be about build-id based
lookup. So I'd really rather keep the warnings separate.
[1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/
[2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/
[3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/
[4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/
[5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/
Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
A user supplied an executable and a remote logfile that could be used
to crash gdb. The problem is that the BFD section for a particular
symbol was null, because the section was not marked "allocated".
Digging deeper, the problem was that elfread.c dropped the section for
absolute symbols. This patch fixes the crash.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30431
Add convenience first_loc methods to struct breakpoint (const and
non-const overloads). A subsequent patch changes the list of locations
to be an intrusive_list and makes the actual list private, so these
spots would need to change from:
b->loc
to something ugly like:
*b->locations ().begin ()
That would make the code much heavier and not readable. There is a
surprisingly big number of places that access the first location of
breakpoints. Whether this is correct, or these spots fail to consider
the possibility of multi-location breakpoints, I don't know. But
anyhow, I think that using this instead:
b->first_loc ()
conveys the intention better than the other two forms.
Change-Id: Ibbefe3e4ca6cdfe570351fe7e2725f2ce11d1e95
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Add three convenience methods to struct breakpoint:
- has_locations: returns true if the breakpoint has at least one
location
- has_single_location: returns true if the breakpoint has exactly one
location
- has_multiple_locations: returns true if the breakpoint has more than
one location
A subsequent patch changes the list of breakpoints to be an
intrusive_list, so all these spots would need to change. But in any
case, I think that this:
if (b->has_multiple_locations ())
conveys the intention better than:
if (b->loc != nullptr && b->loc->next != nullptr)
Change-Id: Ib18c3605fd35d425ef9df82cb7aacff1606c6747
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
In the current code, when execute the following test on LoongArch:
$ make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
=== gdb Summary ===
# of expected passes 111
# of unexpected failures 62
According to IFUNC's working process [1]. first time the IFUNC function
is called, the dynamic linker will not simply fill the .got.plt entry
with the actual address of IFUNC symbol, it will call the IFUNC resolver
function and take the return address, uses it as the sym-bound address
and puts it in the .got.plt entry. Initial address in .got.plt entry is
not a real function addresss. Depending on the compiler implementation,
some different addresses will be filled in. Most architectures will use
a .plt entry address to fill in the corresponding .got.plt entry.
In gdb, elf_gnu_ifunc_resolve_addr() will be called to return a real
IFUNC function addresss. First check to see if the real address for
the IFUNC symbol has been resolved by the following function:
elf_gnu_ifunc_resolve_name (const char *name, CORE_ADDR *addr_p)
{
if (elf_gnu_ifunc_resolve_by_cache (name, addr_p))
return true;
if (elf_gnu_ifunc_resolve_by_got (name, addr_p))
return true;
return false;
}
in elf_gnu_ifunc_resolve_by_got(), it gets the contents of the
.got.plt entry and determines if the contents is the correct address
by calling elf_gnu_ifunc_record_cache(). Based on the IFUNC working
principle analysis above, the address filled in the .got.plt entry is
not the actual target function address initially, it would be a .plt
entry address corresponding symbol like *@plt. In this case, gdb just
go back to execute the resolver function and puts the return address
in the .got.plt entry. After that, gdb can get a real ifun address via
.got.plt entry.
On LoongArch, initially, each address filled in the .got.plt entries
is the first .plt entry address. Some architectures such as LoongArch
define the symbol _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt
section. This symbol is the first plt entry, so gdb needs to check
this symbol in elf_gnu_ifunc_record_cache().
On LoongArch .got.plt and .plt section as follow:
$objdump -D gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-0-0-0
...
0000000120010008 <.got.plt>:
120010008: ffffffff 0xffffffff
12001000c: ffffffff 0xffffffff
...
120010018: 20004000 ll.w $zero, $zero, 64(0x40)
12001001c: 00000001 0x00000001
120010020: 20004000 ll.w $zero, $zero, 64(0x40)
120010024: 00000001 0x00000001
120010028: 20004000 ll.w $zero, $zero, 64(0x40)
12001002c: 00000001 0x00000001
120010030: 20004000 ll.w $zero, $zero, 64(0x40)
120010034: 00000001 0x00000001
...
Disassembly of section .plt:
0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>:
120004000: 1c00018e pcaddu12i $t2, 12(0xc)
120004004: 0011bdad sub.d $t1, $t1, $t3
120004008: 28c021cf ld.d $t3, $t2, 8(0x8)
12000400c: 02ff51ad addi.d $t1, $t1, -44(0xfd4)
120004010: 02c021cc addi.d $t0, $t2, 8(0x8)
120004014: 004505ad srli.d $t1, $t1, 0x1
120004018: 28c0218c ld.d $t0, $t0, 8(0x8)
12000401c: 4c0001e0 jirl $zero, $t3, 0
0000000120004020 <__libc_start_main@plt>:
120004020: 1c00018f pcaddu12i $t3, 12(0xc)
120004024: 28ffe1ef ld.d $t3, $t3, -8(0xff8)
120004028: 4c0001ed jirl $t1, $t3, 0
12000402c: 03400000 andi $zero, $zero, 0x0
0000000120004030 <abort@plt>:
120004030: 1c00018f pcaddu12i $t3, 12(0xc)
120004034: 28ffc1ef ld.d $t3, $t3, -16(0xff0)
120004038: 4c0001ed jirl $t1, $t3, 0
12000403c: 03400000 andi $zero, $zero, 0x0
0000000120004040 <gnu_ifunc@plt>:
120004040: 1c00018f pcaddu12i $t3, 12(0xc)
120004044: 28ffa1ef ld.d $t3, $t3, -24(0xfe8)
120004048: 4c0001ed jirl $t1, $t3, 0
12000404c: 03400000 andi $zero, $zero, 0x0
...
With this patch:
$make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
=== gdb Summary ===
#of expected passes 173
[1] https://sourceware.org/glibc/wiki/GNU_IFUNC
Signed-off-by: Hui Li <lihui@loongson.cn>
PR gdb/29257 points out a possible double free when debuginfod is in
use. Aside from some ugly warts in the symbol code (an ongoing
issue), the underlying issue in this particular case is that elfread.c
seems to assume that symfile_bfd_open will return NULL on error,
whereas in reality it throws an exception. As this code isn't
prepared for an exception, bad things result.
This patch fixes the problem by introducing a non-throwing variant of
symfile_bfd_open and using it in the affected places.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29257
OBJF_REORDERED is set for nearly every object format. And, despite
the ominous warnings here and there, it does not seem very expensive.
This patch removes the flag entirely.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
[ This is a simplified rewrite of an earlier submission "[RFC][gdb/symtab] Add
maint set symbol-read-order", submitted here (
https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html
). ]
With the test-case included in this patch, we run into:
...
(gdb) file dwarf2-and-ctf
(gdb) print var_ctf^M
'var_ctf' has unknown type; cast it to its declared type^M
...
The problem is that the executable contains both ctf and dwarf2, so the ctf
info (which contains the type information about var_ctf) is ignored.
GDB has support for handling multiple debug formats, but the common use case
for ctf is to be used when dwarf2 is not present, and gdb reflects that,
assuming that by reading ctf in addition there won't be any extra information,
so it's not worth the additional cycles and memory.
Add a new command "set/show always-read-ctf on/off", that when on forces
unconditional reading of ctf, allowing us to do:
...
(gdb) set always-read-ctf on
(gdb) file dwarf2-and-ctf
(gdb) print var_ctf^M
$2 = 2^M
...
The setting is off by default, preserving current behaviour.
A bit of background on the relevance of reading order: the formats have a
priority relationship between them, where reading earlier means lower
priority. By reading the format with the most detail last, we ensure it has
the highest priority, which makes sure that in case there is overlapping info,
the most detailed info is found. This explains the current reading order of
mdebug, stabs and dwarf2.
Add the unconditional reading of ctf before dwarf2, because it's less detailed
than dwarf2. The conditional reading of ctf is still done after the attempt to
read dwarf2, necessarily so because we only know whether there's dwarf2 after
we've tried to read it.
The new command allow us to replace uses of -Wl,--strip-debug added in commit
908a926ec4 ("[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed") by
uses of "set always-read-ctf on", but I've left that for another commit.
Tested on x86_64-linux.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
This introduces the set_lval method on value, one step toward removing
deprecated_lval_hack. Ultimately I think the goal should be for some
of these set_* methods to be replaced with constructors; but I haven't
done this, as the series is already too long. Other 'deprecated'
methods can probably be handled the same way.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Currently, when GDB loads debug information from a separate debug
file, there are a couple of warnings that could be produced if things
go wrong.
In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
warning if the separate debug file doesn't include any actual debug
information, and in separate_debug_file_exists (symfile.c) we can warn
if the CRC checksum in the separate debug file doesn't match the
checksum in the original executable.
The problem here is that, when looking up debug information, GDB will
try several different approaches, lookup by build-id, lookup by
debug-link, and then a lookup from debuginfod. GDB can potentially
give a warning from an earlier attempt, and then succeed with a later
attempt. In the cases I have run into this is primarily a warning
about some out of date debug information on my machine, but then GDB
finds the correct information using debuginfod. This can be confusing
to a user, they will see warnings from GDB when really everything is
working just fine.
For example:
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \
does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
This diagnostic was printed on Fedora 33 even when the correct
debuginfo was downloaded.
In this patch I propose that we defer any warnings related to looking
up debug information from a separate debug file. If any of the
approaches are successful then GDB will not print any of the warnings.
As far as the user is concerned, everything "just worked". Only if
GDB completely fails to find any suitable debug information will the
warnings be printed.
The crc_mismatch test compiles two executables: crc_mismatch and
crc_mismatch-2 and then strips them of debuginfo creating separate
debug files. The test then replaces crc_mismatch-2.debug with
crc_mismatch.debug to trigger "CRC mismatch" warning. A local
debuginfod server is setup to supply the correct debug file, now when
GDB looks up the debug info no warning is given.
The build-id-no-debug-warning.exp is similar to the previous test. It
triggers the "separate debug info file has no debug info" warning by
replacing the build-id based .debug file with the stripped binary and
then loading it to GDB. It then also sets up local debuginfod server
with the correct debug file to download to make sure no warnings are
emitted.
The gdbarch "return_value" can't correctly handle variably-sized
types. The problem here is that the TYPE_LENGTH of such a type is 0,
until the type is resolved, which requires reading memory. However,
gdbarch_return_value only accepts a buffer as an out parameter.
Fixing this requires letting the implementation of the gdbarch method
resolve the type and return a value -- that is, both the contents and
the new type.
After an attempt at this, I realized I wouldn't be able to correctly
update all implementations (there are ~80) of this method. So,
instead, this patch adds a new method that falls back to the current
method, and it updates gdb to only call the new method. This way it's
possible to incrementally convert the architectures that I am able to
test.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
Update elf_gnu_ifunc_resolve_by_cache() and elf_gnu_ifunc_resolve_by_got()
to use gdbarch_iterate_over_objfiles_in_search_order() in order to
restrict the objfile traversal to the initial namespace.
In order to extend this to other namespaces, we'd need to provide context,
e.g. via an objfile inside that namespace.
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
This replaces frame_id_eq with operator== and operator!=. I wrote
this for a version of this series that I later abandoned; but since it
simplifies the code, I left this patch in.
Approved-by: Tom Tomey <tom@tromey.com>
The call to debuginfod_debuginfo_query in elf_symfile_read is given
objfile->original_name as the filename to print when downloading the
objfile's debuginfo.
In some cases original_name is prefixed with gdb's working directory
even though the objfile is not located in the working directory. This
causes debuginfod to display the wrong path of the objfile during a download.
Fix this by using the objfile's bfd filename instead.
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to
removing some manual memory management, this fixes a use-after-free
that was introduced by the registry rewrite series. The issue there
was that, in some cases, registry shutdown could refer to memory that
had already been freed. This help fix the bug by delaying the
destruction of the BFD reference (and thus the per-bfd object) until
after the registry has been shut down.
Introduce symtab_create_debug_printf and symtab_create_debug_printf_v,
to print the debug messages enabled by "set debug symtab-create".
Change-Id: I442500903f72d4635c2dd9eaef770111f317dc04
This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes. The result is less code
than the previous setup. It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.
The existing type-safe "key" class is replaced with the equivalent
template class. This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.
All existing users of the old C-like API are now converted to use the
type-safe API. This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.
The old "save/free" two-phase process is removed, and replaced with a
single "free" phase. No existing code used both phases.
The old "free" callbacks took a parameter for the enclosing container
object. However, this wasn't truly needed and is removed here as
well.
This converts location_spec_to_string to a method of location_spec,
simplifying the code using it, as it no longer has to use
std::unique_ptr::get().
Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5
Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs. This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:
breakpoint::location;
breakpoint::loc;
"location" is the location spec, and "loc" is the resolved locations.
And then, we have a method called "locations()", which returns the
resolved locations as range...
The location spec type is presently called event_location:
/* Location we used to set the breakpoint. */
event_location_up location;
and it is described like this:
/* The base class for all an event locations used to set a stop event
in the inferior. */
struct event_location
{
and even that is incorrect... Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events. E.g., "list" works with location specs.
To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec". Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.
Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
Even after the previous patches reworking the inheritance of several
breakpoint types, the present breakpoint hierarchy looks a bit
surprising, as we have "breakpoint" as the superclass, and then
"base_breakpoint" inherits from "breakpoint". Like so, simplified:
breakpoint
base_breakpoint
ordinary_breakpoint
internal_breakpoint
momentary_breakpoint
ada_catchpoint
exception_catchpoint
tracepoint
watchpoint
catchpoint
exec_catchpoint
...
The surprising part to me is having "base_breakpoint" being a subclass
of "breakpoint". I'm just refering to naming here -- I mean, you'd
expect that it would be the top level baseclass that would be called
"base".
Just flipping the names of breakpoint and base_breakpoint around
wouldn't be super great for us, IMO, given we think of every type of
*point as a breakpoint at the user visible level. E.g., "info
breakpoints" shows watchpoints, tracepoints, etc. So it makes to call
the top level class breakpoint.
Instead, I propose renaming base_breakpoint to code_breakpoint. The
previous patches made sure that all code breakpoints inherit from
base_breakpoint, so it's fitting. Also, "code breakpoint" contrasts
nicely with a watchpoint also being typically known as a "data
breakpoint".
After this commit, the resulting hierarchy looks like:
breakpoint
code_breakpoint
ordinary_breakpoint
internal_breakpoint
momentary_breakpoint
ada_catchpoint
exception_catchpoint
tracepoint
watchpoint
catchpoint
exec_catchpoint
...
... which makes a lot more sense to me.
I've left this patch as last in the series in case people want to
bikeshed on the naming.
"code" has a nice property that it's exactly as many letters as
"base", so this patch didn't require any reindentation. :-)
Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66
After the previous patches, only base_breakpoint subclasses use
add_location(sal), so we can move it to base_breakpoint (a.k.a. base
class for code breakpoints).
This requires a few casts here and there, but always at spots where
you can see from context what the breakpoint's type actually is.
I inlined new_single_step_breakpoint into its only caller exactly for
this reason.
I did try to propagate more use of base_breakpoint to avoid casts, but
that turned out unwieldy for this patch.
Change-Id: I49d959322b0fdce5a88a216bb44730fc5dd7c6f8
Add a getter and a setter for a minimal symbol's type. Remove the
corresponding macro and adjust all callers.
Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
A change to BFD caused a gdb regression when using the Ada "catch
exception" feature. The bug is visible when a shared library throws
an exception that is caught in the main executable.
This was discussed here:
https://sourceware.org/pipermail/binutils/2021-July/117538.html
This patch implements Alan's proposed fix, namely to use VERSYM_HIDDEN
rather than the name when deciding to install a version-less symbol.
The internal test case is identical to the catch_ex_std.exp that is
in-tree, so I haven't added a new test. I could not make that one
fail on x86-64 Linux, though. It's possible that maybe I'd have to
update the system linker first, but I didn't want to try that.
Regression tested on x86-64 Fedora 32.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
Now that the quick functions are separate from the object file format,
there's no need to have elfread.c push a new entry on the objfile 'qf'
list. Instead, this detail can be pushed into the DWARF reader. That
is what this patch implements.
I wasn't sure whether lazy reading still makes sense or not. It's
still only used by ELF, and only in certain situations (like vfork, I
think). It may not be carrying its weight, so we may want to consider
removing this in the future.
Also, I'm unclear on why the various indices are only used for ELF.
This seems sub-optimal. However, I haven't tried to address that
here.
gdb/ChangeLog
2021-03-28 Tom Tromey <tom@tromey.com>
* elfread.c (can_lazily_read_symbols): Move to dwarf2/read.c.
(elf_symfile_read): Simplify.
* dwarf2/read.c (struct lazy_dwarf_reader): Move from elfread.c.
(make_lazy_dwarf_reader): New function.
(make_dwarf_gdb_index, make_dwarf_debug_names): Now static.
(dwarf2_initialize_objfile): Return void. Remove index_kind
parameter. Push on 'qf' list.
* dwarf2/public.h (dwarf2_initialize_objfile): Change return
type. Remove 'index_kind' parameter.
(make_dwarf_gdb_index, make_dwarf_debug_names): Don't declare.
An earlier patch neglected to delete a forward declaration of
elf_sym_fns_lazy_psyms. This is no longer defined. This patch
removes it.
gdb/ChangeLog
2021-03-27 Tom Tromey <tom@tromey.com>
* elfread.c (elf_sym_fns_lazy_psyms): Don't declare.
I noticed that I forgot to make a change in my series to make it
possible to attach multiple debug readers to an objfile. In one spot,
elf_symfile_read still clears the 'qf' list. However, this should
have been removed toward the end of that series.
This patch fixes the offending spot. Tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-03-27 Tom Tromey <tom@tromey.com>
* elfread.c (elf_symfile_read): Don't clear 'qf'.
The current_top_target function is a hidden dependency on the current
inferior. Since I'd like to slowly move towards reducing our dependency
on the global current state, remove this function and make callers use
current_inferior ()->top_target ()
There is no expected change in behavior, but this one step towards
making those callers use the inferior from their context, rather than
refer to the global current inferior.
gdb/ChangeLog:
* target.h (current_top_target): Remove, make callers use the
current inferior instead.
* target.c (current_top_target): Remove.
Change-Id: Iccd457036f84466cdaa3865aa3f9339a24ea001d
