But PR gdb/20126 highlights a case where GDB emits a large number of
warnings like:
warning: Can't open file /anon_hugepage (deleted) during file-backed mapping note processing
warning: Can't open file /dev/shm/PostgreSQL.1150234652 during file-backed mapping note processing
warning: Can't open file /dev/shm/PostgreSQL.535700290 during file-backed mapping note processing
warning: Can't open file /SYSV604b7d00 (deleted) during file-backed mapping note processing
... etc ...
when opening a core file. This commit aims to avoid at least some of
these warnings.
What we know is that, for at least some of these cases, (e.g. the
'(deleted)' mappings), the content of the mapping will have been
written into the core file itself. As such, the fact that the file
isn't available ('/SYSV604b7d00' at least is a shared memory mapping),
isn't really relevant, GDB can still provide access to the mapping, by
reading the content from the core file itself.
What I propose is that, when processing the file backed mappings, if
all of the mappings for a file are covered by segments within the core
file itself, then there is no need to warn the user that the file
can't be opened again. The debug experience should be unchanged, as
GDB would have read from the in-core mapping anyway.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30126
Editing maint.h with clangd shows some errors about obj_section and
objfile being unknown. Add some forward declarations for them.
Change-Id: Ic4dd12a371198fdf740892254a8f2c1fae2846b9
In PR gdb/31846 the user reported an issue where GDB is unable to find
the build-id within an ELF, despite the build-id being
present (confirmed using readelf).
The user was able to try several different builds of GDB, and in one
build they observed the warning:
warning: BFD: FILENAME: unable to decompress section .debug_info
But in may other builds of GDB this warning was missing.
There are, I think, a couple of issues that the user is running into,
but this patch is about why the above warning is often missing from
GDB's output.
I wasn't able to reproduce a corrupted .debug_info section such that
the above warning would be triggered, but it is pretty easy to patch
the _bfd_elf_make_section_from_shdr function (in bfd/elf.c) such that
the call to bfd_init_section_decompress_status is reported as a
failure, thus triggering the warning. There is a patch that achieves
this in the bug report.
I did this, and can confirm that on my build of GDB, I don't see the
above warning, even though I can confirm that the _bfd_error_handler
call (in _bfd_elf_make_section_from_shdr) is being reached.
The problem is back in format.c, in bfd_check_format_matches. This
function intercepts all the warnings and places them into a
per_xvec_messages structure. These warnings are then printed with a
call to print_and_clear_messages.
If bfd_check_format_matches finds a single matching format, then
print_and_clear_messages, will print all warnings associated with that
single format.
But if no format matches, print_and_clear_messages will print all the
warnings, so long as all targets have emitted the same set of
warnings, and unfortunately, that is not the case for me.
The warnings are collected by iterating over bfd_target_vector and
trying each target. My target happens to be x86_64_elf64_vec, and, as
expected this target appears in bfd_target_vector.
However, bfd_target_vector also includes DEFAULT_VECTOR near the top.
And in my build, DEFAULT_VECTOR is x86_64_elf64_vec. Thus, for me,
the x86_64_elf64_vec entry appears twice in bfd_target_vector, this
means that x86_64_elf64_vec ends up being tried twice, and, as each
try generates one warning, the x86_64_elf64_vec entry in the
per_xvec_messages structure, has two warnings, while the other
per_xvec_messages entries only have one copy of the warning.
Because of this difference, print_and_clear_messages decides not to
print any of the warnings, which is not very helpful.
I considered a few different approaches to fix this issue:
We could de-duplicate warnings in the per_xvec_messages structure as
new entries are added. So for any particular xvec, each time a new
warning arrives, if the new warning is identical to an existing
warning, then don't record it. This might be an interesting change in
the future, but for now I rejected this solution as it felt like a
bodge, the duplicate warnings aren't really from a single attempt at
an xvec, but are from two distinct attempts at the same xvec. And so:
I wondered if we could remove the duplicate entries from
bfd_target_vector. Or if we could avoid processing the same xvec
twice maybe? For the single DEFAULT_VECTOR this wouldn't be too hard
to do, but bfd_target_vector also includes SELECT_VECS, which I think
could contain more duplicates. Changing bfd_check_format_matches to
avoid attempting any duplicate vectors would now require more
complexity than a single flag, and I felt there was an easier
solution, which was:
I propose that within bfd_check_format_matches, within the loop that
tries each entry from bfd_target_vector, as we switch to each vector
in turn, we should delete any existing warnings within the
per_xvec_messages structure for the target vector we are about to try.
This means that, if we repeat a target, only the last set of warnings
will survive.
With this change in place, print_and_clear_messages now sees the same
set of warnings for each target, and so prints out the warning
message.
Additionally, while I was investigating this issue I managed to call
print_and_clear_messages twice. This caused a crash because the first
call to print_and_clear_messages frees all the associated memory, but
leaves the per_xvec_messages::next field pointing to the now
deallocated object. I'd like to propose that we set the next field to
NULL in print_and_clear_messages. This clearly isn't needed so long
as print_and_clear_messages is only called once, but (personally) I
like to set pointers back to NULL if the object they are pointing to
is free and the parent object is going to live for some additional
time. I can drop this extra change if people don't like it.
This change doesn't really "fix" PR gdb/31846, but it does mean that
the warning about being unable to decompress .debug_info should now be
printed consistently, which is a good thing.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31846
Reviewed-By: Alan Modra <amodra@gmail.com>
The recently included gdb.base/dlmopen-ns-ids.exp test can sometimes
fail the call to get_integer_valueof when trying to check the namespace
ID of the fourth dlopened SO, for apparently no reason.
What's happening is that the call to get_first_so_ns doesn't necessarily
consume the GDB prompt, and so get_integer_valueof will see the prompt
immediately and not find the value the test is looking for.
To fix this, the test was changed so that we consume all of the output
of the command "info sharedlibrary", but only set the namespace ID for
the first occurrence of the SO we're looking for. The command now also
gets the solib name as a parameter, to reduce the amount of output.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom de Vries <tdevries@suse.de>
commit 2707d55e539ef323dd14a1293e762bf3d9739ee7
Author: Michael Matz <matz@suse.de>
Date: Mon Mar 31 15:57:08 2025 +0200
skipped the LTO archive member even when the earlier item is also an
archive. Instead, skip the LTO archive member only if the earlier item
is a shared library.
bfd/
PR ld/32846
PR ld/32854
* elflink.c (elf_link_add_archive_symbols): Skip the LTO archive
member only if the earlier item is a shared library.
ld/
PR ld/32846
PR ld/32854
* testsuite/ld-plugin/lto.exp: Run ld/32846 test.
* testsuite/ld-plugin/pr32846a.c: New file.
* testsuite/ld-plugin/pr32846b.c: Likewise.
* testsuite/ld-plugin/pr32846c.c: Likewise.
* testsuite/ld-plugin/pr32846d.c: Likewise.
* testsuite/ld-plugin/pr32846e.c: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Ignore the following spellcheck warning:
...
$ codespell --config gdb/contrib/setup.cfg gdb/unittests
gdb/unittests/rsp-low-selftests.c:54: fo ==> of, for, to, do, go
...
and add gdb/unittests to the pre-commit codespell configuration.
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.dwarf2/fission-with-type-unit.exp with a remote
host configuration, say host board local-remote-host and target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) maint expand-symtabs^M
During symbol reading: Could not find DWO CU \
fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0x2d7 \
[in module /home/remote-host/fission-with-type-unit]^M
warning: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced \
by CU at offset 0x2d7 [in module /home/remote-host/fission-with-type-unit]^M
(gdb) FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs
...
Fix this by adding the missing download to remote host of the .dwo file.
Tested by running make-check-all.sh on x86_64-linux.
When writing the test, I copied these copyright entries from another
file but forgot to adjust the dates, do that now.
Change-Id: Ie458ad4ec81062b5ef24f78334f3d0920c99b318
Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
changed the dates in Makefile.in. Re-run `autoreconf` in the gdbsupport
directory to fix that up.
Change-Id: Ifcdb6f2257e7a456439dfc3e7848db934a4b16b4
Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
changed the dates in Makefile.in. Re-run `autoreconf` in the sim
directory to fix that up.
Change-Id: Ia02a54e5330d77b490cc7745eee3d281c7888eec
Commit d01e823438 ("Update copyright dates to include 2025") changed the
dates in the gnulib imported source files, it probably shouldn't have.
Re-run update-gnulib.sh to restore those files.
gnulib/Makefile.in was also incorrectly modified, running the script
fixes that too.
Change-Id: I5d081f3438b9480130a92f59fd9fede33c121f9c
With a gdb 15.2 based package and test-case
gdb.threads/infcall-from-bp-cond-simple.exp, I ran into:
...
Thread 2 "infcall-from-bp" hit Breakpoint 3, function_with_breakpoint () at \
infcall-from-bp-cond-simple.c:51
51 return 1; /* Nested breakpoint. */
Error in testing condition for breakpoint 2:
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(function_with_breakpoint) will be abandoned.
When the function is done executing, GDB will silently stop.
[Thread 0x7ffff73fe6c0 (LWP 951822) exited]
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_bp_cond_hits_breakpoint: continue
...
The test fails because it doesn't expect the "[Thread ... exited]" message.
I have tried to reproduce this test failure, both using 15.2 and current
trunk, but haven't managed.
Regardless, I think the message is harmless, so allow it to occur, both in
run_bp_cond_segfaults and run_bp_cond_hits_breakpoint.
Tested on x86_64-linux.
PR testsuite/32785
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32785
On riscv64-linux, with test-case gdb.base/vla-optimized-out.exp I ran into:
...
(gdb) p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: $exp: o1: printed size of optimized out vla
...
The variable a has type 0xbf:
...
<1><bf>: Abbrev Number: 12 (DW_TAG_array_type)
<c0> DW_AT_type : <0xe3>
<c4> DW_AT_sibling : <0xdc>
<2><c8>: Abbrev Number: 13 (DW_TAG_subrange_type)
<c9> DW_AT_type : <0xdc>
<cd> DW_AT_upper_bound : 13 byte block:
a3 1 5a 23 1 8 20 24 8 20 26 31 1c
(DW_OP_entry_value: (DW_OP_reg10 (a0));
DW_OP_plus_uconst: 1; DW_OP_const1u: 32;
DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
DW_OP_lit1; DW_OP_minus)
...
which has an upper bound using a DW_OP_entry_value, and since the
corresponding call site contains no information to resolve the value of a0 at
function entry:
...
<2><6b>: Abbrev Number: 6 (DW_TAG_call_site)
<6c> DW_AT_call_return_pc: 0x638
<74> DW_AT_call_origin : <0x85>
...
evaluting the dwarf expression fails, and we get <optimized out>.
My first thought was to try breaking at *f1 instead of f1 to see if that would
help, but actually the breakpoint resolved to the same address.
In other words, the inferior is stopped at function entry.
Fix this by resolving DW_OP_entry_value when stopped at function entry by
simply evaluating the expression.
This handles these two cases (x86_64, using reg rdi):
- DW_OP_entry_value: (DW_OP_regx: 5 (rdi))
- DW_OP_entry_value: (DW_OP_bregx: 5 (rdi) 0; DW_OP_deref_size: 4)
Tested on x86_64-linux.
Tested gdb.base/vla-optimized-out.exp on riscv64-linux.
Tested an earlier version of gdb.dwarf2/dw2-entry-value-2.exp on
riscv64-linux, but atm I'm running into trouble on that machine (cfarm92) so
I haven't tested the current version there.
So far IBM z17 was identified as arch15. Add the real name, as it has
been announced. [1]
[1]: IBM z17 announcement letter, AD25-0015,
https://www.ibm.com/docs/en/announcements/z17-makes-more-possible
gas/
* config/tc-s390.c (s390_parse_cpu): Add z17 as alternate CPU
name for arch15.
* doc/c-s390.texi: Likewise.
* doc/as.texi: Likewise.
opcodes/
* s390-mkopc.c (main): Add z17 as alternate CPU name for arch15.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
The Linaro CI reported a regression [1] in test-case
gdb.base/step-over-syscall.exp due to commit 674d4856730 ("[gdb/testsuite] Fix
gdb.base/step-over-syscall.exp with glibc 2.41").
Investigation shows that it's a progression in the sense that the test-case
fails at a later point than before.
The cause for the test-case failure is that an atomic sequence
ldaex/adds/strex is not skipped over when instruction stepping, leading to a
hang (in the sense of not being able to instruction-step out of the loop
containing the atomic sequence).
The arm target does have support for recognizing atomic sequences, but it
fails because it doesn't recognize the ldaex insn.
Fix this by:
- adding a new function ldaex_p which recognizes ldaex instructions, based
on information found in opcodes/arm-dis.c, and
- using ldaex_p in thumb_deal_with_atomic_sequence_raw.
I was not able to reproduce the failure in its original setting, but I
was able to do so using a test.c:
...
static void exit (int status) {
while (1)
;
}
void _start (void) {
int a = 0;
__atomic_fetch_add (&a, 1, __ATOMIC_ACQUIRE);
exit (0);
}
...
compiled like this:
...
$ gcc test.c -march=armv8-a -mfloat-abi=soft -nostdlib -static
...
giving this atomic sequence of 32-bit Thumb-2 instructions:
...
100ce: e8d3 1fef ldaex r1, [r3]
100d2: f101 0101 add.w r1, r1, #1
100d6: e843 1200 strex r2, r1, [r3]
...
Without the fix, after 100 stepi's we're still in _start (and likewise with
10.000 stepi's):
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100dc in _start ()
1: x/i $pc
=> 0x100dc <_start+26>: bne.n 0x100ce <_start+12>
...
but with the fix we've managed to progress to exit:
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100c0 in exit ()
1: x/i $pc
=> 0x100c0 <exit+8>: b.n 0x100c0 <exit+8>
...
Having addressed the "-mthumb" case, do we need a similar fix for "-marm"?
Adding "-marm" in the compilation line mentioned above gives the following
atomic sequence:
...
100e4: e1931e9f ldaex r1, [r3]
100e8: e2811001 add r1, r1, #1
100ec: e1832f91 strex r2, r1, [r3]
...
and gdb already recognizes it as such because of this statement:
...
if ((insn & 0xff9000f0) != 0xe1900090)
return {};
...
The trouble with this statement is that it requires knowledge of arm
instruction encoding to understand which cases it does and doesn't cover.
Note that the corresponding comment only mentions ldrex:
...
/* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */
...
but evidently at least some forms of ldaex are also detected.
So, also use ldaex_p in arm_deal_with_atomic_sequence_raw. This may or may
not be redundant, but at least ldaex_p is explicit and precise about what it
supports.
Likewise for stlex (generated when using __ATOMIC_RELEASE instead of
__ATOMIC_ACQUIRE in the example above).
Tested in arm-linux chroot on aarch64-linux.
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Co-Authored-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/32796
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32796
[1] https://linaro.atlassian.net/browse/GNU-1541
print_doc_line uses a static buffer and manually manages memory. I
think neither of these is really needed, so this patch rewrites the
function to use std::string. The new implementation tries to avoid
copying when possible.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Commit 71a48752660b ("gdb/dwarf: remove create_dwo_cu_reader")
introduced a regression when handling files compiled with "-gsplit-dwarf
-fdebug-types-section" (at least with clang):
$ cat test.cpp
#include <vector>
int main()
{
std::vector<int> v;
return v.size ();
}
$ clang++ -O0 test.cpp -g -gdwarf-5 -gsplit-dwarf -fdebug-types-section -o test
$ ./gdb -nx -q --data-directory=data-directory ./test -ex "maint expand-symtabs"
Reading symbols from ./test...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6159: internal-error: setup_type_unit_groups: Assertion `per_cu->is_debug_types' failed.
In the main file, we have a skeleton CU with a certain DWO ID:
0x00000000: Compile Unit: ..., unit_type = DW_UT_skeleton, ..., DWO_id = 0x146eaa4daf5deef2, ...
In the .dwo file, the first unit is a type unit with a certain type
signature:
0x00000000: Type Unit: ..., unit_type = DW_UT_split_type, ..., type_signature = 0xb499dcf29e2928c4, ...
and the split compile unit matching the DWO ID from the skeleton from
the main file comes later:
0x0000117f: Compile Unit: ..., unit_type = DW_UT_split_compile, ..., DWO_id = 0x146eaa4daf5deef2, ...
The problem introduced by the aforementioned commit is that when
creating a dwo_unit structure representing the type unit, we use the
signature (DWO id) from the skeleton, instead of the signature from the
type unit's header. As a result, all dwo_units get created with the
same signature (the DWO id) and only the first unit gets inserted in the
hash table. When looking up the comp unit by DWO ID later on, we
wrongly find the type unit, and try to expand a type unit as a comp
unit, hitting the assert.
Before that commit, we passed `reader.cu ()` to lookup_dwo_id, which
yields a dwarf2_cu built from parsing the type unit's header. This
dwarf2_cu contains the comp_unit_header with the correct signature. Fix
the code to use `reader.cu ()` again.
Another thing that enables this bug is the fact that since DWARF 5, type
and compile units are all in .debug_info, and therefore read by
create_cus_hash_table, so they both end up in dwo_file::cus. Type units
should end up in dwo_file::tus, otherwise they won't be found by
lookup_dwo_cutu. This bug hasn't given me trouble so far, so I'm not
fixing it right now, but it's on my todo list.
The problem can be seen with some tests, when using the
dwarf5-fission-debug-types board:
$ make check TESTS="gdb.cp/expand-sals.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.cp/expand-sals.exp ...
FAIL: gdb.cp/expand-sals.exp: gdb_breakpoint: set breakpoint at main (GDB internal error)
But this patch also adds a DWARF assembler-based test that triggers the
internal error.
Note that the new test does not use the build_executable_and_dwo_files
proc, because I found that it is subtly broken and doesn't work to put
multiple units in a single .dwo file. The debug abbrev offset field in
the second unit's header would be 0, when it should have been something
else. The problem is that no linking is ever done to generate the .dwo
file, so the relocation that would apply for this field is never
applied. Instead, I generate two DWARF debug infos separately and link
the .dwo file using gdb_compile, it seems to work fine.
Change-Id: I96f809c56f703e25f72b8622c32e6bb91de20d6a
Approved-By: Tom Tromey <tom@tromey.com>
Fix what looks like a copy paste error resulting in the wrong abbrev
section name. The resulting section name in my test was
".debug_info.dwo.dwo", when it should have been ".debug_abbrev.dwo".
Change-Id: I82166d8ac6eaf3c3abc15d2d2949d00c31fe79f4
Approved-By: Tom Tromey <tom@tromey.com>
Add support to the DWARF assembler to generate DWARF 5 split compile
units. The assembler knows how to generate DWARF < 5 split compile
units (fission), DWARF 5 compile units, but not DWARF 5 split compile
units. What's missing is:
- using the right unit type in the header: skeleton for the unit in the
main file and split_compile for the unit in the DWO file
- have a way for the caller to specify the DWO ID that will end up in
the unit header
Add a dwo_id parameter to the cu proc. In addition to specifying the
DWO ID, the presence of this parameter tells the assembler to use the
skeleton or split_compile unit type.
This is used in a subsequent patch.
Change-Id: I05d9b189a0843ea6c2771b1d5e5a91762426dea9
Approved-By: Tom Tromey <tom@tromey.com>
I'm currently fixing bugs and performance issues when GDB encounters
this particular configuration. Since split DWARF + type units makes GDB
take some code paths not taken by any other board files, I think it
deserves to be its own board file. One particularity is that the
produced .dwo files have a .debug_info.dwo section that contains some
ype units, in addition to the compile unit.
Add that board to make-check-all.sh.
Change-Id: I245e6f600055a27e0c31f1a4a9af1f68292fe18c
Approved-By: Tom Tromey <tom@tromey.com>
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
and move it from gdb.base to gdb.arch as it's a target specific test.
Reviewed-by: Maciej W. Rozycki <macro@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
The GNU Assembler User Guide says that the right shift operator ">>"
in an expression is the same as the C operator.
On LoongArch the assembler directives and instructions do not treat
negative numbers ">>" the same way. The directives treats negative
numbers ">>" as logical right shifts while the instructions treats them
as arithmetic right shifts.
The right shift of negative numbers in the instructions may be changed
from an arithmetic right shift to a logical right shift in the future,
and a warning is issued for this.
Consider the following scenario:
...
$ cat hello
int
main (void)
{
printf ("hello\n");
return 0;
}
$ gcc -x c hello -g
$ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x4005db: file hello, line 6.
Starting program: /data/vries/gdb/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Temporary breakpoint 1, main () at hello:6
6 printf ("hello\n");
...
This doesn't produce highlighting for line 6, because:
- pygments is used for highlighting instead of source-highlight, and
- pygments guesses the language for highlighting only based on the filename,
which in this case doesn't give a clue.
Fix this by:
- adding a language parameter to the extension_language_ops.colorize interface,
- passing the language as found in the debug info, and
- using it in gdb.styling.colorize to pick the pygments lexer.
The new test-case gdb.python/py-source-styling-2.exp excercises a slightly
different scenario: it compiles a c++ file with a .c extension, and checks
that c++ highlighting is done instead of c highlighting.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/30966
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966
I noticed that if deferred curses initialization fails, for instance when
using TERM=dumb, and we try the same again, we run into the same error:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
...
I think it's better to try deferred curses initialization only once.
Fix this by changing bool tui_finish_init into a tribool, and using
TRIBOOL_UNKNOWN to represent the "initialization failed" state, such that we
get instead:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
when a shared library defines 'foo@@FOO' (default version),
a static archive defines 'foo', the shared lib comes in front
of the archive and under effect of --as-needed, and the requesting
object file uses LTO, then the link editor was wrongly including
the definition from the static archive. It must use the one
from the shared lib, like in the non-LTO or the --no-as-needed case.
See the added testcase that would wrongly print "FAIL" before
this patch.
The problem stems from several connected problems:
(1) only the decorated symbol was entered into first_hash (the hash
table designed to handle definition order in the pre-LTO-plugin
phase of the symbol table walks)
(2) in the archive symbol walk only the undecorated name would be
looked up in first_hash (and hence not found due to (1))
(3) in the archive symbol walk first_hash would only be consulted
when the linker hash table had a defined symbol. In pre-LTO
phase shared lib symbols aren't entered into the linker symbol
table.
So: add also the undecorated name into first_hash when it stems from
a default version and consult first_hash in the archive walker also
for currently undefined symbols. If it has an entry which doesn't
point to the archive, then it comes from an earlier library (shared or
static), and so _this_ archive won't provide the definition.
Sanity check symbol string table offsets, and tidy structs. "long"
isn't a good choice for _l_zeroes and _l_offset since it can be 64
bits which blows out the size of the symbol struct unnecessarily.
Also, all of the sizes in internal_ldsym need only be 32 bits, but I
made them size_t because I didn't want to audit all expressions using
them for overflow.
bfd/
* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_symtab): Sanity
check symbol _l_offset.
(xcoff_link_add_dynamic_symbols),
(xcoff_link_check_dynamic_ar_symbols): Likewise.
include/
* coff/xcoff.h (struct internal_ldhdr): Tidy types.
(struct internal_ldsym): Use uint32_t for _l_zeroes and _l_offset.
Much of the xcoff code is not well protected against fuzzed object file
attacks. This sanity checks some values in ".loader".
* xcofflink.c (xcoff_get_ldhdr): New function.
(_bfd_xcoff_get_dynamic_symtab_upper_bound),
(_bfd_xcoff_canonicalize_dynamic_symtab),
(_bfd_xcoff_get_dynamic_reloc_upper_bound),
(_bfd_xcoff_canonicalize_dynamic_reloc),
(xcoff_link_add_dynamic_symbols),
(xcoff_link_check_dynamic_ar_symbols): Use xcoff_get_ldhdr.
GDB has had basic support for linkage namespaces for some time already,
but only in the sense of managing multiple copies of the same shared
object being loaded, and a very fragile way to find the correct copy of
a symbol (see PR shlibs/32054).
This commit is the first step in improving the user experience around
multiple namespace support. It introduces a user-friendly identifier for
namespaces, in the format [[<number>]], that will keep consistent between
dlmopen and dlclose calls. The plan is for this identifier to be usable
in expressions like `print [[1]]::var` to find a specific instance of a
symbol, and so the identifier must not be a valid C++ or Ada namespace
identifier, otherwise disambiguation becomes a problem. Support for
those expressions has not been implemented yet, it is only mentioned to
explain why the identifier looks like this.
This syntax was chosen based on the C attributes, since nothing in GDB
uses a similar syntax that could confuse users. Other syntax options
that were explored were "#<number>" and "@<number>". The former was
abandoned because when printing a frame, the frame number is also
printed with #<number>, so in a lot of the context in which that the
identifier would show up, it appears in a confusing way. The latter
clashes with the array printing syntax, and I believe that the having
"@N::foo" working completely differently to "foo@2" would also lead to a
bad user experience.
The namespace identifiers are stored via a vector inside svr4_info
object. The vector stores the address of the r_debug objects used by
glibc to identify each namespace, and the user-friendly ID is the index
of the r_debug in the vector. This commit also introduces a set storing
the indices of active namespaces. The glibc I used to develop this patch
(glibc 2.40 on Fedora 41) doesn't allow an SO to be loaded into a
deactivated namespace, and requesting a new namespace when a namespace
was previously closed will reuse that namespace. Because of how this is
implemented, this patch lets GDB easily track the exact namespace IDs
that the inferior will see.
Finally, two new solib_ops function pointers were added, find_solib_ns
and num_active_namespaces, to allow code outside of solib-svr4 to find
and use the namespace identifiers and the number of namespaces,
respectively. As a sanity check, the command `info sharedlibrary` has
been changed to display the namespace identifier when the inferior has
more than one active namespace. With this final change, a couple of tests
had to be tweaked to handle the possible new column, and a new test has
been created to make sure that the column appears and disappears as
needed, and that GDB can track the value of the LMID for namespaces.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Per the Microsoft PE documentation, XP and earlier on i686 require the
Size field to be 64, rather than the actual size as required on other
architectures. I have confirmed Windows 11 accepts either 64 or the
actual size for i386 images, but only the actual size for x86_64 images.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
This is filled in with the rva of _load_config_used if defined (much
like _tls_used), and the size is the first 32-bit value at that symbol.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
Rationalize the error messages in _bfd_XXi_final_link_postscript().
They now all correctly refer to DataDirectory instead of DataDictionary,
and use unified format strings, so fewer translations are needed.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
This function returns the leading char to use, so we cannot just assume
it will always be '_' or '\0'.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
The need for this has disappeared with dc12032bca08 ("Remove m68k-aout
and m68k-coff support"); avoid the unnecessary indirection.
Sadly, with ld/pe-dll.c using the wrapper, the removal requires moving
the declaration out of libcoff.h, to properly export the underlying BFD
function.
Size being set for a symbol isn't a strict requirement in ELF. For ones
not having their size set, fall back to the same logic as used for non-
ELF, non-COFF symbols.
While there switch to using elf_symbol_from() instead of kind of open-
coding it.
Like ELF for all symbols, COFF can record size for at least function
ones. Use that - if available - in preference to the distance-to-next-
symbol heuristic.
To be able to use the new test there, make TI C54x follow TI C4x in
providing .sdef to cover for .def already having different meaning.
Remove all duplicate symbols which can be in SymLst. The duplication
is due to processing of both static and dynamic symbols. The
Stabs::removeDupSyms function is called before computing symbol
aliases.
Introduce a new vector function (i.e., truncate()), that truncates a
vector lenght to the given new count. This functionis used by
removeDupSyms function.
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>
This patch refactors a number of gprofng internal functions for using
more BFD data types and functions.
Stabs::readSymSec is a function which reads the symbols of an ELF file
mapping them into an internal structure. To use BFD asymbols, the
Elf::elf_getsym is changed from custom reading of the symbols from
.symtab and .dynsym section to BFD enable functions. A new function is
introduced which returns the number of either static or dynamic symbols,
named Elf::elf_getSymCount. Both Elf functions are used by
Stabs::readSymSec refactoring.
Also, this patch removes reading symbols, SUNW_ldnsym section as it is
only used by now defunct Studio compiler. However, it adds the reading
of both static and dynamic symbols, previously, only either one was
processed.
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>
check_Relocs() function is not anylonger required as it can only
handle Studio compiler relocs, now defunct. Remove this function.
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>
