A recent static analyzer run flagged that program_space::exec_close
could be using a pointer after it has been freed. This is not true, as
the pointer is never dereferenced, the address is used for comparisons.
However, to avoid false positives from static analyzers (or bogus
security bugs), this commit makes the code stop looking like a UAF by
moving the unique_ptr into a local unique_ptr, so that there is no way
someone would think memory could be used after being freed.
Tom de Vries [Wed, 30 Apr 2025 11:56:19 +0000 (13:56 +0200)]
[gdb/testsuite] Don't compile read1.so with -fsanitize
After building gdb with:
...
CFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread -fno-exceptions
CXXFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread
...
when doing:
...
$ cd build/gdb
$ make check-read1 RUNTESTFLAGS=gdb.threads/clone-attach-detach.exp
...
I run into:
...
Running /data/vries/gdb/src/gdb/testsuite/gdb.threads/clone-attach-detach.exp ...
ThreadSanitizer:DEADLYSIGNAL
==4799==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 \
(pc 0x7f636029a947 bp 0x7f635dfbf090 sp 0x7f635dfbf028 T4824)
==4799==The signal is caused by a READ memory access.
==4799==Hint: address points to the zero page.
ThreadSanitizer:DEADLYSIGNAL
ThreadSanitizer: nested bug in the same thread, aborting.
...
This doesn't happen when doing the same from build/gdb/testsuite, because
CFLAGS doesn't get propagated from build/gdb.
I'm not sure what is the root cause here, but when building with
-fsanitize, I'm interested in running the sanitizer on gdb, not on testsuite
utility libraries that are used with expect.
Fix this by skipping -fsanitize when compiling read1.so and readmore.so.
Tested on x86_64-linux, by rebuilding read1.so and running the test-case.
Tom de Vries [Wed, 30 Apr 2025 11:41:20 +0000 (13:41 +0200)]
[gdb/testsuite] Handle asm frame in gdb.python/py-missing-objfile.exp
On arm-linux, with test-case gdb.python/py-missing-objfile.exp I get:
...
(gdb) whatis global_exec_var^M
type = volatile exec_type^M
(gdb) FAIL: $exp: initial sanity check: whatis global_exec_var
...
instead of the expected "type = volatile struct exec_type".
The problem is that the current language is ASM instead of C, because the
inner frame at the point of the core dump has language ASM:
...
#0 __libc_do_syscall () at libc-do-syscall.S:47
#1 0xf7882920 in __pthread_kill_implementation () at pthread_kill.c:43
#2 0xf784df22 in __GI_raise (sig=sig@entry=6) at raise.c:26
#3 0xf783f03e in __GI_abort () at abort.c:73
#4 0x009b0538 in dump_core () at py-missing-objfile.c:34
#5 0x009b0598 in main () at py-missing-objfile.c:46
...
Tom de Vries [Wed, 30 Apr 2025 07:49:58 +0000 (09:49 +0200)]
[gdb/build] Fix Wformat errors in gdb/riscv-tdep.c
When building gdb with --enable-targets=all on arm-linux, I run into:
...
gdb/riscv-tdep.c: In function ‘bool try_read(regcache*, int, ULONGEST&)’:
gdb/riscv-tdep.c:4887:18: error: format ‘%lx’ expects argument of type \
‘long unsigned int’, but argument 2 has type ‘ULONGEST’ \
{aka ‘long long unsigned int’} [-Werror=format=]
4887 | warning (_("Can not read at address %lx"), addr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
and a few more Wformat errors, due to commit b9c7eed0c24 ("This commit adds
record full support for rv64gc instruction set").
Kito Cheng [Tue, 29 Apr 2025 03:40:15 +0000 (11:40 +0800)]
RISC-V: Mark fgt.*/fge.* as instruction alias
They are instruction alias, but not mark correctly, and seems like we
don't have a good way to verify that since the disassembler doesn't
disassemble instruction into alias.
Simon Marchi [Tue, 29 Apr 2025 19:57:49 +0000 (15:57 -0400)]
gdb/dwarf: change a bunch of functions to be methods of cooked_index_worker_debug_info
Move a few functions exclusively used to process units to become methods
of cooked_index_worker_debug_info. Rename them to a more consistent
name scheme, which gets rid of outdated naming. The comments were also
quite outdated.
Change-Id: I2e7dcc2e4ff372007dcb4f6c3d34187c9cc2da05 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 24 Apr 2025 20:43:58 +0000 (16:43 -0400)]
gdb/dwarf: move cooked_index_worker_debug_info up
The next patch moves some functions to be methods of
cooked_index_worker_debug_info. Move cooked_index_worker_debug_info
above those functions, to make that easier (methods can't be defined
before the class declaration).
Change-Id: I7723cb42efadb2cc86f2227b3c2fb275e2d620f9 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 24 Apr 2025 20:01:47 +0000 (16:01 -0400)]
gdb/dwarf: clean up some cutu_reader::is_dummy() calls
This patch tries to standardize the places where we check if units are
dummy. When checking if a unit is dummy, it is not necessary to check
for some other conditions.
- cutu_reader::is_dummy() is a superset of cutu_reader::cu() returning
nullptr, so it's not necessary to check if the cu method return
nullptr if also checking if the unit is dummy.
- cutu_reader::is_dummy() is a superset of cutu_reader::top_level_die()
returning nullptr, so same deal.
Remove some spots that check for these conditions in addition to
cutu_reader::is_dummy().
In addition, also remove the checks for:
!new_reader->top_level_die ()->has_children
in cooked_indexer::ensure_cu_exists. IMO, it is not useful to special
case the units having a single DIE. Especially in this function, which
deals with importing things from another unit, a unit with a single DIE
would be an edge case that should not happen with good debug info. I
think it's preferable to have simpler code.
Change-Id: I4529d7b3a0bd2891a60f41671de8cfd3114adb4a Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 24 Apr 2025 20:01:46 +0000 (16:01 -0400)]
gdb/dwarf: avoid cutu_reader moves
In process_psymtab_comp_unit and ensure_cu_exists, we create a temporary
cutu_reader on the stack, then move it to a heap allocated cutu_reader
once we confirmed the unit is not dummy. I think it's unnecessary to
create a temporary cutu_reader. The only downside of not doing so is that if it
ends up that the CU is dummy, we made an allocation/deallocation for
nothing. Dummy CUs are a rare thing, it shouldn't change anything.
This allows removing the cutu_reader move constructor.
Change-Id: I44742d471c495055ee46db41c0e7bdfbd2d5c0b7 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 24 Apr 2025 17:36:28 +0000 (13:36 -0400)]
gdb/dwarf: read multiple .debug_info.dwo sections
When building with gcc, with flags -gdwarf-5, -gsplit-dwarf and
-fdebug-types-section, the resulting .dwo files contain multiple
.debug_info.dwo sections. One for each type unit and one for the
compile unit. This is correct, as per DWARF 5, section F.2.3 ("Contents
of the Split DWARF Object Files"):
The split DWARF object files each contain the following sections:
...
.debug_info.dwo (for the compilation unit)
.debug_info.dwo (one COMDAT section for each type unit)
...
GDB currently assumes that there is a single .debug_info.dwo section,
causing unpredictable behavior. For example, sometimes this crash:
==81781==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x508000007a71 at pc 0x58704d32a59c bp 0x7ffc0acc0bb0 sp 0x7ffc0acc0ba0
READ of size 1 at 0x508000007a71 thread T0
#0 0x58704d32a59b in bfd_getl32 /home/smarchi/src/binutils-gdb/bfd/libbfd.c:846
#1 0x58704ae62dce in read_initial_length(bfd*, unsigned char const*, unsigned int*, bool) /home/smarchi/src/binutils-gdb/gdb/dwarf2/leb.c:92
#2 0x58704aaf76bf in read_comp_unit_head(comp_unit_head*, unsigned char const*, dwarf2_section_info*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:47
#3 0x58704aaf8f97 in read_and_check_comp_unit_head(dwarf2_per_objfile*, comp_unit_head*, dwarf2_section_info*, dwarf2_section_info*, unsigned char const*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:193
#4 0x58704b022908 in create_dwo_unit_hash_tables /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6233
#5 0x58704b0334a5 in open_and_init_dwo_file /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7588
#6 0x58704b03965a in lookup_dwo_cutu /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7935
#7 0x58704b03a5b1 in lookup_dwo_comp_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8009
#8 0x58704aff5b70 in lookup_dwo_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2802
The first time that locate_dwo_sections gets called for a
.debug_info.dwo section, dwo_sections::info gets initialized properly.
The second time it gets called for a .debug_info.dwo section, the size
field in dwo_sections::info gets overwritten with the size of the second
section. But the buffer remains pointing to the contents of the first
section, because the section is already "read in". So the size does not
match the buffer. And even if it did, we would only keep the
information about one .debug_info.dwo, out of the many.
First, add an assert in locate_dwo_sections to make sure we don't
try to fill in a dwo section info twice. Add the assert to other
functions with the same pattern, while at it.
Then, change dwo_sections::info to be a vector of sections (just like we
do for type sections). Update locate_dwo_sections to append to that
vector when seeing a new .debug_info.dwo section. Update
open_and_init_dwo_file to read the units from each section.
The problem can be observed by running some tests with the
dwarf5-fission-debug-types target board. For example,
gdb.base/condbreak.exp crashes (with the ASan failure shown above)
before the patch and passes after).
Simon Marchi [Tue, 29 Apr 2025 19:31:45 +0000 (15:31 -0400)]
gdb/dwarf: scan .debug_info.dwo just once
When building -gsplit-dwarf and -fdebug-types-section in DWARF 5, the
resulting .dwo files will typically have a .debug_info.dwo section with
multiple type units followed by one compile unit:
$ llvm-dwarfdump -F -color a-test.dwo | grep ' Unit'
0x00000000: Type Unit: length = 0x000008a0, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'vector<int, std::allocator<int> >', type_signature = 0xb499dcf29e2928c4, type_offset = 0x0023 (next unit at 0x000008a4)
0x000008a4: Type Unit: length = 0x00000099, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'allocator<int>', type_signature = 0x496a8791a842701b, type_offset = 0x0023 (next unit at 0x00000941)
...
0x000015c1: Compile Unit: length = 0x00000f58, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0xe8e359820d1c5803 (next unit at 0x0000251d)
In open_and_init_dwo_file, we call create_dwo_cus_hash_table, which
scans the section, looking for compile units, then call
create_dwo_debug_types_hash_table, which scans the section again,
looking for type units. It would make more sense to scan the section
just once and handle both compile and type units at the same time.
To achieve this, add create_dwo_unit_hash_tables, which knows how to
handle both unit kinds in a single scan. It replaces
create_dwo_cus_hash_table and create_dwo_debug_type_hash_table. Change
open_and_init_dwo_file to call it.
Note that I removed the DWARF version check in open_and_init_dwo_file
when processing .debug_type.dwo sections: in DWARF 5, the
.debug_type.dwo sections will just not exist, so the
`dwo_file->sections.types` vector will be empty.
Change-Id: I6e51d0ca06c258e0bf0e59927d62ae2df314a162 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 24 Apr 2025 17:36:26 +0000 (13:36 -0400)]
gdb/dwarf: scan DWARF 5 DWO CUs by just reading the header
create_dwo_cus_hash_table is implemented by creating a cutu_reader
(which is somewhat heavy) for all units in a .dwo file. The purpose of
this cutu_reader is to be able to get the DWO ID, if it is specified by
a DW_AT_GNU_dwo_id attribute.
In DWARF 5, however, the DWO ID is available in the CU header. We can
access it without accessing the DIEs, by just reading the header, which
is more lightweight. Add a new code path to create_dwo_cus_hash_table
that does that. The logic is copied from
create_dwo_debug_type_hash_table, which does this already.
This change helps circumvent a performance problem I want to fix (the
same I was trying to fix in this patch [1]) when loading a file built
with -gdwarf-5, -gsplit-dwarf and -fdebug-types-section. In this
configuration, the produced .dwo files contain one compile unit and many
type units each. All units in a given .dwo share the same abbrev table.
Creating a cutu_reader for each unit meant re-reading the same abbrev
table over and over. What's particularly bad is that this is done with
the dwo_lock held, preventing other indexing threads from making
progress.
To give a rough idea, here's the time take by each worker to index units
before this patch (on a rather large program):
Time for "DWARF indexing worker": wall 18.627, user 0.885, sys 0.042, user+sys 0.927, 5.0 % CPU
Time for "DWARF indexing worker": wall 18.888, user 0.862, sys 0.042, user+sys 0.904, 4.8 % CPU
Time for "DWARF indexing worker": wall 19.172, user 1.848, sys 0.069, user+sys 1.917, 10.0 % CPU
Time for "DWARF indexing worker": wall 19.297, user 1.544, sys 0.051, user+sys 1.595, 8.3 % CPU
Time for "DWARF indexing worker": wall 19.545, user 3.408, sys 0.084, user+sys 3.492, 17.9 % CPU
Time for "DWARF indexing worker": wall 19.759, user 4.221, sys 0.117, user+sys 4.338, 22.0 % CPU
Time for "DWARF indexing worker": wall 19.789, user 4.187, sys 0.105, user+sys 4.292, 21.7 % CPU
Time for "DWARF indexing worker": wall 19.825, user 4.933, sys 0.135, user+sys 5.068, 25.6 % CPU
And the times with this patch:
Time for "DWARF indexing worker": wall 0.163, user 0.089, sys 0.029, user+sys 0.118, 72.4 % CPU
Time for "DWARF indexing worker": wall 0.176, user 0.096, sys 0.041, user+sys 0.137, 77.8 % CPU
Time for "DWARF indexing worker": wall 0.265, user 0.167, sys 0.054, user+sys 0.221, 83.4 % CPU
Time for "DWARF indexing worker": wall 0.353, user 0.257, sys 0.060, user+sys 0.317, 89.8 % CPU
Time for "DWARF indexing worker": wall 0.524, user 0.399, sys 0.088, user+sys 0.487, 92.9 % CPU
Time for "DWARF indexing worker": wall 0.648, user 0.517, sys 0.107, user+sys 0.624, 96.3 % CPU
Time for "DWARF indexing worker": wall 0.657, user 0.523, sys 0.107, user+sys 0.630, 95.9 % CPU
Time for "DWARF indexing worker": wall 0.753, user 0.612, sys 0.120, user+sys 0.732, 97.2 % CPU
Simon Marchi [Wed, 16 Apr 2025 04:09:06 +0000 (00:09 -0400)]
gdb/dwarf: replace some "compile unit" terminology with "unit"
In DWARF 5 (and even previous versions, with type units), compile units
are just one type of units. In many places, we still use "compile
units" when in reality it would be better to talk about "units" (unless
we specifically want to talk about compile units).
Rename comp-unit-head.{c.h} to unit-head.{c,h}, and do a big pass of
renames in it to remove the specific mentions of compile units, where in
fact we want to talk about units in general.
Change-Id: Ia06c90ccb25756c366f269a12620f2f7c8378adb Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 17 Apr 2025 19:23:54 +0000 (15:23 -0400)]
gdb: add some scoped_time_its to profile startup time
I'm investigating some issues where GDB takes a lot of time to start
up (read: for the DWARF index to be ready to do anything useful).
Adding those scoped_time_it instances helped me gain some insights about
where GDB spends time. I think they would be useful to have upstream,
to make investigating future problems easier. It would also be useful
to be able to give some numbers in the commit messages.
Here's an example of what GDB outputs:
Time for "minsyms install worker": wall 0.045, user 0.040, sys 0.004, user+sys 0.044, 97.8 % CPU
Time for "minsyms install worker": wall 0.511, user 0.457, sys 0.048, user+sys 0.505, 98.8 % CPU
Time for "minsyms install worker": wall 1.513, user 1.389, sys 0.111, user+sys 1.500, 99.1 % CPU
Time for "minsyms install worker": wall 1.688, user 1.451, sys 0.102, user+sys 1.553, 92.0 % CPU
Time for "minsyms install worker": wall 1.897, user 1.518, sys 0.089, user+sys 1.607, 84.7 % CPU
Time for "minsyms install worker": wall 2.811, user 2.558, sys 0.231, user+sys 2.789, 99.2 % CPU
Time for "minsyms install worker": wall 3.257, user 3.049, sys 0.188, user+sys 3.237, 99.4 % CPU
Time for "minsyms install worker": wall 3.617, user 3.089, sys 0.211, user+sys 3.300, 91.2 % CPU
Time for "DWARF indexing worker": wall 19.517, user 0.894, sys 0.075, user+sys 0.969, 5.0 % CPU
Time for "DWARF indexing worker": wall 19.807, user 0.891, sys 0.086, user+sys 0.977, 4.9 % CPU
Time for "DWARF indexing worker": wall 20.270, user 1.559, sys 0.119, user+sys 1.678, 8.3 % CPU
Time for "DWARF indexing worker": wall 20.329, user 1.878, sys 0.147, user+sys 2.025, 10.0 % CPU
Time for "DWARF indexing worker": wall 20.848, user 3.483, sys 0.224, user+sys 3.707, 17.8 % CPU
Time for "DWARF indexing worker": wall 21.088, user 4.285, sys 0.295, user+sys 4.580, 21.7 % CPU
Time for "DWARF indexing worker": wall 21.109, user 4.501, sys 0.274, user+sys 4.775, 22.6 % CPU
Time for "DWARF indexing worker": wall 21.198, user 5.087, sys 0.319, user+sys 5.406, 25.5 % CPU
Time for "DWARF skeletonless type units": wall 4.024, user 3.858, sys 0.115, user+sys 3.973, 98.7 % CPU
Time for "DWARF add parent map": wall 0.092, user 0.086, sys 0.004, user+sys 0.090, 97.8 % CPU
Time for "DWARF finalize worker": wall 0.278, user 0.241, sys 0.009, user+sys 0.250, 89.9 % CPU
Time for "DWARF finalize worker": wall 0.307, user 0.304, sys 0.000, user+sys 0.304, 99.0 % CPU
Time for "DWARF finalize worker": wall 0.727, user 0.719, sys 0.000, user+sys 0.719, 98.9 % CPU
Time for "DWARF finalize worker": wall 0.913, user 0.901, sys 0.003, user+sys 0.904, 99.0 % CPU
Time for "DWARF finalize worker": wall 0.776, user 0.767, sys 0.004, user+sys 0.771, 99.4 % CPU
Time for "DWARF finalize worker": wall 1.897, user 1.869, sys 0.006, user+sys 1.875, 98.8 % CPU
Time for "DWARF finalize worker": wall 2.534, user 2.512, sys 0.005, user+sys 2.517, 99.3 % CPU
Time for "DWARF finalize worker": wall 2.607, user 2.583, sys 0.006, user+sys 2.589, 99.3 % CPU
Time for "DWARF finalize worker": wall 3.142, user 3.094, sys 0.022, user+sys 3.116, 99.2 % CPU
Change-Id: I9453589b9005c3226499428ae9cab9f4a8c22904 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 17 Apr 2025 19:23:53 +0000 (15:23 -0400)]
gdb: add scoped_time_it
New in v2:
- actually use m_enabled in the constructor and destructor
- output using gdb_stdlog->write_async_safe instead of gdb_printf
scoped_time_it is a small utility that measures and prints how much time
a given thread spent in a given scope. Similar to the time(1) command,
it prints the time spent in user mode, system mode, and the wall clock
time. It also prints the CPU utilization percentage, which is:
(user + sys) / wall
This can help spot cases where the workload is not well balanced between
workers, or the CPU utilization is not optimal (perhaps due to
contention around a lock for example).
To use it, just add it in some scope. For instance, a subsequent patch
adds it here:
On destruction, if enabled, it prints a line showing the time spent by
that thread, similar to what time(1) prints.
The example above prints this (one line for each worker thread):
Time for "DWARF indexing worker": wall 0.173, user 0.120, sys 0.034, user+sys 0.154, 89.0 % CPU
Time for "DWARF indexing worker": wall 0.211, user 0.144, sys 0.047, user+sys 0.191, 90.5 % CPU
Time for "DWARF indexing worker": wall 0.368, user 0.295, sys 0.057, user+sys 0.352, 95.7 % CPU
Time for "DWARF indexing worker": wall 0.445, user 0.361, sys 0.072, user+sys 0.433, 97.3 % CPU
Time for "DWARF indexing worker": wall 0.592, user 0.459, sys 0.113, user+sys 0.572, 96.6 % CPU
Time for "DWARF indexing worker": wall 0.739, user 0.608, sys 0.115, user+sys 0.723, 97.8 % CPU
Time for "DWARF indexing worker": wall 0.831, user 0.677, sys 0.140, user+sys 0.817, 98.3 % CPU
Time for "DWARF indexing worker": wall 0.949, user 0.789, sys 0.144, user+sys 0.933, 98.3 % CPU
The object is only enabled if per_command_time (controlled by "maint set
per-command time") is true at construction time. I wanted to avoid
adding a new command for now, but eventually if there are too many
scoped_time_it around the code base and we want to be able to enabled
them selectively (e.g. just the ones in the DWARF reader, or in the
symbol searching functions, etc), we could have a dedicated command for
that.
I added this functionality to GDB because it relies on gdb_printf and
per_command_time, but if we ever need it in gdbsupport, I'm sure we
could find a way to put it there.
Change-Id: I5416ac1448f960f44d85f8449943d994198a271e Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 25 Apr 2025 14:13:36 +0000 (08:13 -0600)]
Handle base type without DW_AT_byte_size
DWARF says that a base type can have DW_AT_bit_size, without
DW_AT_byte_size. However, gdb does not correctly handle this; in
fact, it crashes, as pointed out in this LLVM merge request:
https://github.com/llvm/llvm-project/pull/137123
This patch reworks the base type size logic a bit to handle this
situation.
Tested-by: Kevin Buettner <kevinb@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
Keith Seitz [Tue, 29 Apr 2025 16:08:38 +0000 (09:08 -0700)]
[gdb/contrib] Add script to license check new files
While reading through gdb-patches backlog after a return
from PTO, I noticed that a newly added file was licensed
with "MIT", and that license was not listed in Fedora's
gdb.spec file. [Fedora no longer supports "effective"
licenses.]
That lead me to this simple script which generates a list
of all the newly added files between two given commits and
scans these files for licenses.
Example usage:
bash$ cd /path/to/binutils-gdb/gdb
bash$ ./contrib/license-check-new-files.sh -s gdb-15-branchpoint gdb-16-branchpoint
Scanning directories gdb*/...
gdb/contrib/common-misspellings.txt: no longer in repo?
gdb/contrib/spellcheck.sh: no longer in repo?
gdbsupport/unordered_dense.h: MIT
I don't think anything in here is Fedora- or RPM-specific,
so I'd like to submit this for consideration for inclusion
in contrib/. I believe other distros may find it useful.
Tom de Vries [Tue, 29 Apr 2025 15:30:07 +0000 (17:30 +0200)]
[gdb/testsuite] Fix gdb.python/py-objfile.exp with gcc 15
When running test-case gdb.python/py-objfile.exp with gcc 15, we get:
...
(gdb) p main^M
$2 = {int (void)} 0x40066c <main>^M
(gdb) FAIL: $exp: print main with debug info
...
The source file declares main as "int main ()"
...
and until C23 this meant a non-prototype function declaration and we'd have:
...
(gdb) p main^M
$2 = {int ()} 0x40066c <main>^M
...
However, starting C23 "int main ()" is simply equivalent to "int main (void)".
Fix this by:
- declaring main as "int main (void)" in the test-case, and
- updating the regexp to expect an "int (void)" prototype.
Likewise in gdb.base/jit-bfd-name.exp.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
Tom de Vries [Tue, 29 Apr 2025 15:14:46 +0000 (17:14 +0200)]
[gdb/testsuite] Don't use string_to_regexp twice in gdb.base/options.exp
In test-case gdb.base/options.exp, in proc test_completer_recognizes we have:
...
set expected_re [string_to_regexp $input_line]
test_gdb_complete_unique $input_line $expected_re
...
However, the first thing we do in proc test_gdb_complete_unique is to apply
string_to_regexp to the second argument:
...
proc test_gdb_complete_unique {
input_line
complete_line
{append_char " "}
{max_completions false}
{testname ""}
} {
set complete_line_re [string_to_regexp $complete_line]
test_gdb_complete_unique_re \
$input_line \
$complete_line_re \
$append_char \
$max_completions\
$testname
}
...
This happens to not cause any FAILs at the moment, but this should be done
only once.
Fix this not using string_to_regexp in proc test_completer_recognizes.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
$ q
...
Fix this in gdbpy_flush by checking for nullptr gdb_stdout/gdb_stderr (and
likewise in ioscm_flush) such that we get instead:
...
$ gdb
(gdb) <q>error detected on stdin
$ q
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Tue, 29 Apr 2025 15:01:55 +0000 (17:01 +0200)]
[gdb] Fix sig_write for null gdb_stderr
When running test-case gdb.tui/tui-layout-asm.exp with target board
dwarf5-fission-debug-types, the test-case fails and I get a core dump:
...
# of unexpected core files 1
...
Looking at the backtrace of the core file, what seems to be happening is that:
- gdbpy_flush attempts to flush gdb_stdout, which is nullptr
- that causes a segfault
- gdb intercepts this and starts to handle it using handle_fatal_signal
- handle_fatal_signal calls sig_write, which attempts to write to gdb_stderr,
which is nullptr,
- that causes another segfault
- gdb exits
I managed to reproduce the problem by the following trigger patch in
stdin_event_handler:
...
- if (error)
+ if (1 || error)
{
current_ui = main_ui;
ui->unregister_file_handler ();
- if (main_ui == ui)
+ if (1 || main_ui == ui)
{
gdb_printf (gdb_stderr, _("error detected on stdin\n"));
+ gdb_stderr = nullptr;
+ gdb_stdout = nullptr;
+ gdb_stdlog = nullptr;
quit_command ((char *) 0, 0);
}
...
which gives us:
...
$ gdb
(gdb) <q>error detected on stdin
Segmentation fault (core dumped)
$ q
...
Fix sig_write to handle the case that gdb_stderr == nullptr, such that we get
instead:
...
$ gdb
(gdb) <q>error detected on stdin
Fatal signal: Segmentation fault
----- Backtrace -----
...
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
$ q
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Tue, 29 Apr 2025 15:01:55 +0000 (17:01 +0200)]
[gdb] Factor out sig_write
Lambda function sig_write:
...
const auto sig_write = [] (const char *msg) -> void
{
gdb_stderr->write_async_safe (msg, strlen (msg));
}
...
is defined a few times.
Factor this out into a regular function.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Sun, 27 Apr 2025 23:12:48 +0000 (07:12 +0800)]
elf: Properly set sh_offset for .tbss sections
Set sh_offset for .tbss sections to their nominal offset after aligning.
They are not loaded from disk so the value doesn't really matter, except
when the .tbss section is the first one in a PT_TLS segment. In that
case, it sets the p_offset for the PT_TLS segment, which according to
the ELF gABI ought to satisfy p_offset % p_align == p_vaddr % p_align.
bfd/
PR ld/32896
* elf.c (assign_file_positions_for_load_sections): Properly set
sh_offset for .tbss sections.
ld/
PR ld/32896
* testsuite/ld-elf/tbss4.d: New file.
* testsuite/ld-elf/tbss4.s: Likewise.
Fixed as specified in the DWARF standard:
The first type of reference can identify any debugging information entry
within the containing unit. This type of reference is an offset from the first
byte of the compilation header for the compilation unit containing
the reference. There are five forms for this type of reference.
There are fixed length forms for one, two, four and eight byte offsets
(respectively, DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, and DW_FORM_ref8).
There is also an unsigned variable length offset encoded form that uses
unsigned LEB128 numbers (DW_FORM_ref_udata).
gprofng/ChangeLog
2025-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
H.J. Lu [Thu, 20 Mar 2025 20:16:34 +0000 (13:16 -0700)]
dwarf: Dump .debug_loclists only for DWARF-5
.debug_loclists section is loaded into debug_information as DWARF-5 debug
info and .debug_loc section is loaded into debug_information as pre-DWARF-5
debug info. When dumping .debug_loc section, we should only process
pre-DWARF-5 debug info in debug_information. When dumping .debug_loclists
section, we should only process DWARF-5 info in debug_information.
binutils/
PR binutils/32809
* dwarf.c (display_debug_loc): Dump .debug_loclists only for
DWARF-5.
ld/
PR binutils/32809
* testsuite/ld-x86-64/dwarf4.s: New file.
* testsuite/ld-x86-64/dwarf5a.s: Likewise.
* testsuite/ld-x86-64/dwarf5b.s: Likewise.
* testsuite/ld-x86-64/pr32809.d: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr32809.
Tom Tromey [Fri, 25 Apr 2025 23:32:33 +0000 (17:32 -0600)]
Fix "set debug parser"
While debugging my longer series, I discovered that I broken "set
debug parser" a couple years ago. This patch fixes it and adds a
minimal test case so that it, hopefully, will not break again.
This patch also adds parser debugging to the C++ name canonicalizer.
We have a discrepancy with 64-bit BFD handling across our component
subdirectories leading to link failures such as:
ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
[...]
with some configurations having a 32-bit host and 64-bit BFD, such as:
`--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
other subdirectorses and has been a regression from commit 1d5269c994bf
("unify 64-bit bfd checks").
For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
combined with this logic in bfd/configure.ac:
case ${host64}-${target64}-${want64} in
*true*)
wordsize=64
bfd64_libs='$(BFD64_LIBS)'
all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
[...]
;;
false-false-false)
wordsize=32
all_backends='$(BFD32_BACKENDS)'
;;
esac
where the value of ${wordsize} switches between 32-bit and 64-bit BFD
via these pieces:
#define BFD_ARCH_SIZE @wordsize@
and:
#if BFD_ARCH_SIZE >= 64
#define BFD64
#endif
in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".
Then ${host64} is determined in bfd/configure.ac from the host's word
size, via the host's pointer size:
if test "x${ac_cv_sizeof_void_p}" = "x8"; then
host64=true
fi
And ${target64} is determined in bfd/configure.ac from the target's word
size:
if test ${target_size} = 64; then
target64=true
fi
Where multiple targets have been requested with `--enable-targets=all'
the presence of any 64-bit target will set "true" here.
Finally ${want64} is set according to `--enable-64-bit-bfd' user option
with an arrangement involving BFD_64_BIT:
BFD_64_BIT
if test $enable_64_bit_bfd = yes ; then
want64=true
else
want64=false
fi
which also, redundantly, checks and sets its result upon the host's word
size. Lastly ${want64} is also selectively set by target fragments in
bfd/config.bfd, which mostly if not completely overlaps with ${target64}
setting as described above.
Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
notice that BFD is 64-bit and do not enable their 64-bit handling where
the host requested is 32-bit and 64-bit BFD has been enabled other than
with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c
enables calls to its numerous own 64-bit backends by checking the BFD64
macro from "bfd.h", however does not actually enable said backends in
its Makefile. Hence the link errors quoted above.
Address the problem then by moving the `--enable-64-bit-bfd' option back
to bfd/configure.ac and remove the call to BFD_64_BIT from there and
then rewrite the macro in terms of checking for the presence of BFD64
macro in "bfd.h", which is the canonical way of determining whether BFD
is 64-bit or not.
Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
fragment used to before the problematic commit:
if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then
run the preprocessor on "bfd.h", which allows to invoke the macro from
configure.ac files placed in subdirectories located at deeper levels, by
relying on the preprocessor's search path.
This requires however that the invokers rely on `all-bfd' rather than
`configure-bfd' for their `configure' invocation stage, because "bfd.h"
is made by `make all' rather than `configure' in bfd/.
Do not cache the result of this check however, as reconfiguring a tree
such as to flip `--enable-64-bit-bfd' on or to change a secondary target
may affect BFD64 and we have no access to information about secondary
targets in BFD_64_BIT.
Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
anywhere.
Last but not least remove the hack from gdb/configure.ac to fail builds
for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds
complete successfully now, having enabled 64-bit BFD implicitly.
Tested-By: Guinevere Larsen <guinevere@redhat.com> Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Alan Modra <amodra@gmail.com> Approved-By: Luis Machado <luis.machado@arm.com>
After running test-case gdb.python/py-color-leak.exp in a container where I
don't have PYTHONDONTWRITEBYTECODE set, I get:
...
$ ls src/gdb/testsuite/gdb.python/__pycache__/
gdb_leak_detector.cpython-313.pyc
...
Fix this by setting sys.dont_write_bytecode to True in the python scripts
importing the module.
Tom Tromey [Tue, 1 Nov 2022 18:48:27 +0000 (12:48 -0600)]
Add "maint canonicalize" command
This adds a new "maint canonicalize" command that can be used to see
the canonical form of a C++ name. I've needed this a few times when
debugging gdb.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tom de Vries <tdevries@suse.de>
It would be useful to tell codespell to ignore blocks of code.
A feature ignore-multiline-regex exists, which can be used to implement this:
...
$ codespell --ignore-multiline-regex \
'codespell:ignore-begin.*codespell:ignore-end'
...
Unfortunately there's a bug in codespell where using -w in
combination with --ignore-multiline-regex drops all newlines in the updated
file.
In absence of a fix, commit this solution disabled, to locally document the
current state of this feature.
Tom de Vries [Fri, 25 Apr 2025 17:22:36 +0000 (19:22 +0200)]
[pre-commit] Add codespell-log commit-msg hook
Now that we're using codespell to check spelling in gdb files, can we use
codespell to bring this spelling warning:
...
$ echo usuable | codespell -
1: usuable
usuable ==> usable
...
to:
...
$ git commit -a -m "Usuable stuff"
...
?
When trying the commit, we get:
...
$ echo "/* bla */" >> gdb/gdb.c
$ git commit -a -m "Usuable stuff"
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
isort................................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
check-include-guards.................................(no files to check)Skipped
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
codespell-commit-msg.....................................................Failed
- hook id: codespell
- duration: 0.06s
- exit code: 65
.git/COMMIT_EDITMSG:1: Usuable ==> Usable
check-include-guards.................................(no files to check)Skipped
$
...
The commit was aborted, but the commit message is still there:
...
$ cat .git/COMMIT_EDITMSG
Usuable stuff
...
We can retry and edit the commit message to clean up the typo:
...
$ git commit -e -F .git/COMMIT_EDITMSG -a
...
but it's a bit cumbersome.
Furthermore, say we fix a typo and want to document this in the commit log, and
do:
...
$ git commit -m "Fixed typo: useable -> usable" -a
...
This commit cannot succeed, unless we add a codespell ignore tag, which feels
like taking it too far.
Both these problems can be addressed by setting things up in such a way that
the commit always succeeds, and codespell output is shown as a hint.
Ideally, we'd tell to pre-commit to implement this using some setting, but
there doesn't seem to be one.
So we use some indirection. Instead of using native codespell, use a local
hook that calls a script gdb/contrib/codespell-log.sh, which calls pre-commit,
which calls codespell.
Using this approach, we get:
...
$ echo "/* bla */" >> gdb/gdb.c
$ git commit -a -m "Usuable stuff"
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
isort................................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
check-include-guards.................................(no files to check)Skipped
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
check-include-guards.................................(no files to check)Skipped
codespell-log............................................................Passed
- hook id: codespell-log
- duration: 0.18s
The recent commit dbbb9cfd3708a5b09b449c6cbc4d74dfec13904d added a
message using %ld to print an std::vector::size, which is of size_t
type. on 64 bit machines, size_t will be an unsigned long int, making
%ld work just fine, but on 32 bit ones, size_t will be unsigned int,
which causes the build to fail.
This commit fixes that by using %zu instead.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32901 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Simon Marchi [Thu, 24 Apr 2025 20:36:02 +0000 (16:36 -0400)]
gdb/dwarf: add dwarf2_cu::find_die method
I added this small helper method in the series I'm writing, to make
finding a DIE by section offset a bit nicer than using the unordered_set
methods. It doesn't have any dependencies, so I thought I would submit
it on its own.
Change-Id: If7313194ab09d9bd6d6a52c24eb6fd9a9c1b76e0 Approved-by: Kevin Buettner <kevinb@redhat.com>
Tom Tromey [Thu, 20 Mar 2025 15:52:08 +0000 (09:52 -0600)]
Use correct sign extension for enumeration types
This changes update_enumeration_type_from_children to use the correct
sign-extension method on the attribute. The logic here is a bit
complicated: if the enum has an underlying type, then we use that
type's signed-ness to interpret attributes; otherwise we must assume
attributes are encoded as signed values.
Tom Tromey [Thu, 20 Mar 2025 13:47:51 +0000 (07:47 -0600)]
Use correct sign for variant part discriminants
The discriminant value for a variant part may be signed or unsigned,
depending on the type of the variant. This patch changes the DWARF
reader to delay interpretation of the relevant attribute until the
signed-ness is known.
Tom Tromey [Wed, 19 Mar 2025 20:04:43 +0000 (14:04 -0600)]
Use correct sign in get_mpz
This changes dwarf2/read.c:get_mpz to use the correct sign-extension
function. Normally a rational constant uses signed values, but a
purely unsigned form also seems fine here. This adds a new
attribute::form_is_strictly_unsigned, which is more precise than
form_is_unsigned (which accepts a lot of forms that aren't really for
ordinary constants).
Tom Tromey [Wed, 19 Mar 2025 13:25:55 +0000 (07:25 -0600)]
Use correct sign for DW_AT_GNU_bias
DW_AT_GNU_bias may be signed or unsigned, depending on the underlying
type. This patch changes the DWARF reader to examine the type before
decoding the attribute.
Tom Tromey [Mon, 10 Mar 2025 16:03:17 +0000 (10:03 -0600)]
Use attribute::signed_constant for fixed-point scale
This changes the DWARF reader to use attribute::signed_constant for
DW_AT_binary_scale and DW_AT_decimal_scale. (FWIW these were the
attributes that first lead me to find this problem.)
Tom Tromey [Mon, 24 Feb 2025 19:26:36 +0000 (12:26 -0700)]
Introduce attribute::signed_constant
This introduces a new method, attribute::signed_constant. This should
be used wherever DWARF specifies a signed integer constant, or where
this is implied by the context. It properly handles sign-extension
for DW_FORM_data*.
To my surprise, there doesn't seem to be a pre-existing sign-extension
function. I've added one to common-utils.h alongside the align
functions.
gdb: update corner case when canonicalizing riscv syscall names
The script syscalls/riscv-canonicalize-syscall-gen.py has been recently
introduced to help support record-full in riscv systems. However, it
was developed before commit 432eca4113d5748ad284a068873455f9962b44fe,
which made the GDB enum more consistent, which forced the python script
to have a corner case for the "gdb_old_mmap" case.
Since the aforementioned commit has already been merged, we need to
update the special case for the mmap syscall. A special case is still
needed because the script would expect that the glibc sources call the
syscall "old_mmap", or that gdb call it "gdb_sys_mmap", neither of which
happens unfortunately.
This commit doesn't change the .c file because it was already fixed by a
different commit, 65ab41b7d5c612b6000b28f4c50bb256b2a9e22b, which was
pushed as obvious to fix the build issues.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
New test - gdb.base/tls-dlobj.exp
This test exercises musl_link_map_to_tls_module_id() and
glibc_link_map_to_tls_module_id(), both of which are in solib-svr4.c.
Prior to writing this test, I had only written what is now named
'musl_link_map_to_tls_module_id' and it worked for both GLIBC and
MUSL. Once I wrote this new test, tls-dlobj.exp, there were a number
of tests which didn't work with GLIBC. This led me to write a
GLIBC-specific link map to module id function, i.e,
'glibc_link_map_to_tls_module_id'.
It only has one compilation scenario, in which the pthread(s) library
is used - as noted in a comment, it became too much of a hassle to try
to KFAIL things, though it certainly could have been done in much the
same was as was done in gdb.base/multiobj.exp. It didn't seem that
important to do so, however, since I believe that the other tests
have adequate coverage for different compilation scenarios.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
New test - gdb.base/tls-multiobj.exp
This test exercises GDB's internal TLS support when both the main
program and several shared libraries have TLS variables. It also
tests existing (non-internal) TLS support too.
It tests using two compilation scenarios, "default", in which
libpthread is not linked with the program and libraries as well
as one which does use libpthread.
It tests link map address to module id mapping code in GDB
in addition to the ability of GDB to traverse TLS data structures
with several libraries in play.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
New test - gdb.base/tls-nothreads.exp
This commit introduces a new test, gdb.base/tls-nothreads.exp.
It has a test case, a C file, which has several TLS variables in the
main program, which, once compiled and linked, should end up (in ELF
files) in .tdata and .tbss. The test compiles the program in a number
of different ways, making sure that each variable is accessible
regardless of how it was compiled.
Note that some of the compilation scenarios end up with a statically
linked executable. Prior to this series of commits, accessing TLS
variables from a statically linked program on Linux did not work.
For certain targets (x86_64, aarch64, s390x, riscv, and ppc64),
all on Linux, support has been added to GDB for accessing thread
local storage in statically linked executables. This test is
important for testing those build scenarios.
But it's also important to make sure that GDB's internal TLS support
works for other scenarios too. In order to accomplish that, the
tests are also run in a mode which forces the internal support to
be used.
It also adds a new file, gdb.base/tls-common.exp.tcl, which includes
some common definitions used by the three new TLS tests, including
the one added by this commit. In particular, it sets a TCL variable,
'internal_tls_linux_targets' which list the targets mentioned earlier.
This means that as internal TLS support is added for other targets,
the target should be listed in just one file as opposed to three
(or more if other tests using tls-common.exp.tcl are added).
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
Internal, but disabled, TLS support for i386
This commit shows how internal TLS address lookup support could
be implemented for the i386 target.
Unfortunately, it doesn't work due to I386_GSBASE_REGNUM being
unavailable for Linux targets. I looked at trying to access the
gsbase register via PTRACE_GET_THREAD_AREA, but did not understand
it well enough to finish it. Since the i386 target is much less
important than it used to be, I gave up working on it.
I don't want to leave this disabled code in our sources, so I
will delete it in the next commit, however, this commit will be
in our git repo, so it'll be available for someone with sufficient
interest in the i386 target to look at.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x
For each architecture, aarch64, x86_64, riscv, ppc64, and s390x,
this commit defines a suitable 'get_tls_dtv_addr' method and,
when necessary, a 'get_tls_dtp_offset' method.
It also registers svr4_tls_get_thread_local_address, defined in
svr4-tls-tdep.c (in an earlier commit), as the
get_thread_local_address gdbarch method. It also registers its
architecture specific code using svr4_tls_register_tls_methods().
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Implement internal TLS address lookup for select Linux targets
This commit adds non-architecture-specific support for internal TLS
address lookup for targets which register their support with the new
file svr4-tls-tdep.c. By "internal", I mean support which does not
rely on libthread_db. Knowledge of how to traverse TLS data
structures is contained in this commit along with the next commit
containing architecture specific knowledge regarding TLS offsets,
registers, and such.
The new function 'svr4_tls_get_thread_local_address' is a gdbarch method.
It should be passed as an argument to
set_gdbarch_get_thread_local_address in architecture specific
<arch>-linux-tdep.c files which wish to offer internal TLS support.
The architecture specific tdep files need to define a get_tls_dtv_addr
method - as the name suggests, it needs to return the address of the
DTV (dynamic thread vector) via architecture specific means. This
usually entails fetching the thread pointer via a register or registers
assigned to this purpose, and then using that value to locate the
address of the DTV from within the TCB (thread control block).
Additionally, some architectures also need to provide a DTP offset,
which is used by the MUSL C library to adjust the value obtained
from a DTV entry to that of the start of the TLS block for a particular
thread. This is provided, when necessary, by a get_tls_dtp_offset
method.
Both methods, get_tls_dtv_addr and get_tls_dtp_offset, are registered
with data structures maintained by linux-tdep.c via the new function
svr4_tls_register_tls_methods(). Thus, for example, on RISC-V,
riscv_linux_init_abi() will make the following two calls, the first
for registering the internal get_thread_local_address gdbarch method
and the second for registering riscv-specific methods for obtaining
the DTV address and DTP offset:
Internal TLS support is provided for two C libraries, GLIBC, and MUSL.
Details for accessing the various TLS data structures differ between
these libraries. As a consequence, linux-tdep.h defines a new enum,
svr4_tls_libc, with values svr4_tls_libc_unknown, svr4_tls_libc_musl,
and svr4_tls_libc_glibc. A new static function libc_tls_sniffer uses
heuristics to (try to) decide whether a program was linked against
GLIBC or MUSL. Working out what the heuristics should be, especially
for statically linked binaries, turned out to be harder than I thought
it would be.
A new maintenance setting, force-internal-tls-address-lookup, has been
added, which, when set to 'on', will (as the name suggests) force the
internal TLS lookup mechanisms to be used. Otherwise, if thread_db
support is available (via the thread stratum), that will be preferred
since it should be more accurate. I expect that this setting will be
mostly used by test cases in the GDB test suite. The new test cases
that are part of this series all use it, with iterations using both
'on' and 'off' for all of the tests therein.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Track and fetch TLS module ids for MUSL and GLIBC
This commit adds, to solib-svr4.h and solib-svr4.c, functions
glibc_link_map_to_tls_module_id and musl_link_map_to_tls_module_id for
use with callers in a new file svr4-tls-tdep.c (which is not in this
commit). It adds a number of helper functions for implementing link
map to module id support.
It also renames existing function 'find_program_interpreter' to
'svr4_find_program_interpreter' and makes it visible to other source
files within GDB. It will be used in the libc sniffing code in
svr4-tls-tdep.c in a later commit in this series. The libc sniffer is
needed in order to know which link map to module id function to call
as the method for determining module ids differs between libc /
dynamic linker implementations. These details are discussed in
comments in the patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Allow TLS access to work in gdb.server/no-thread-db.exp
The patches later in the series add GDB-internal TLS support for
certain targets. This commit updates the "print foo" test in
gdb.server/no-thread-db.exp to accept either a TLS failure (when
libthread_db isn't available) or printing the correct answer, which
will occur when GDB's internal TLS address resolution can be used.
I'm making this change prior to the commits which actually add
the GDB-internal TLS support in order to avoid tripping regression
testers.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Don't attempt to find TLS address when target has no registers
This commit fixes two bugs, one of which is Bug 25807, which occurs
when target_translate_tls_address() is called from
language_defn::read_var_value in findvar.c. I found it while testing on
aarch64; it turned a KFAIL for gdb.threads/tls.exp: print a_thread_local
into a FAIL due to a GDB internal error. Now, with this commit in place,
the KFAIL/FAIL turns into a PASS.
In addition to the existing test just noted, I've also added a test to
the new test case gdb.base/tls-nothreads.exp. It'll be tested, using
different scenarios, up to 8 times:
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: after exit: print tls_tbss_1
There is a related problem that occurs when target_translate_tls_address
is called from find_minsym_type_and_address() in minsyms.c. It can be
observed when debugging a program without debugging symbols when the
program is not executing. I've written a new test for this, but it's
(also) included in the new test case gdb.base/tls-nothreads.exp, found
later in this series. Depending on the target, it can run up to 8
times using different scenarios. E.g., on aarch64, I'm seeing these
PASSes, all of which test this change:
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
In an earlier version of this commit (v4), I was checking whether the
target has registers in language_defn::read_var_value in findvar.c and
in find_minsym_type_and_address in minsyms.c, printing suitable error
messages in each case. In his review of this commit for the v4
series, Tom Tromey asked whether it would be better to do this check
in target_translate_tls_address. I had considered doing that for the
v4 (and earlier) series, but I wanted to print slightly different
messages at each check. Also, read_var_value in findvar.c was already
printing a message in some cases and I had arranged for the later
check in that function to match the original message.
However, while I had added a target-has-registers check at two of the
call sites for target_translate_tls_address, I hadn't added it at the
third call site which is in dwarf_expr_context::execute_stack_op() in
dwarf2/expr.c. I believe that in most cases, this is handled by the
early check in language_defn::read_var_value...
else if (sym_need == SYMBOL_NEEDS_REGISTERS && !target_has_registers ())
error (_("Cannot read `%s' without registers"), var->print_name ());
...but it's entirely possible that dwarf_expr_context::execute_stack_op()
might get called in some other context. So it makes sense to do the
target-has-registers check for that case too. And rather than add yet
another check at that call site, I decided that moving the check and
error message to target_translate_tls_address makes sense.
I had to make the error messages that it prints somewhat more generic.
In particular, when called from language_defn::read_var_value, the
message printed by target_translate_tls_address no longer matches the
earlier message that could be printed (as shown above). That meant
that the test cases which check for this message, gdb.threads/tls.exp,
and gdb.base/tls-nothreads.exp had to be adjusted to account for the
new message. Also, I think it's valuable to the user to know (if
possible) the name of the variable that caused the error, so I've
added an optional parameter to target_translate_tls_address, providing
the name of the variable, if it's known. Therefore, the message
that's printed when the target-has-registers test fails is one of the
following:
When the TLS variable isn't known (due to being called from
dwarf_expr_context::execute_stack_op):
"Cannot translate TLS address without registers"
When the TLS variable is known (from either of the other two call sites
for target_translate_tls_address):
"Cannot find address of TLS symbol `%s' without registers"
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25807 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Andrew Burgess [Thu, 9 Nov 2023 15:28:49 +0000 (15:28 +0000)]
gdb: add remote argument passing unit tests
This commit adds some remote argument passing unit tests. There are
not many tests right now -- there are known bugs in the remote
argument passing mechanism (see PR gdb/28392) -- but some simple cases
are covered here, and I plan to add additional tests once I've fixed
more of the problems with the existing argument handling code.
The tests take an inferior argument string, this is the string that
GDB would carry around as inferior::m_args. This string is then split
using gdb::remote_args::split, this gives a vector of strings, these
are the strings that are passed over the remote protocol. These split
strings are validated as part of the test.
The split strings are then combined using gdb::remote_args::join which
gives the inferior argument string that gdbserver will use, this is
held in server.cc as program_args, this joined string is then checked
as part of the test.
There are no changes to GDB's behaviour as part of this commit, other
than adding the new tests which can be run with:
(gdb) maintenance selftest remote-args
Running selftest remote-args.
Ran 1 unit tests, 0 failed
Andrew Burgess [Thu, 9 Nov 2023 14:47:34 +0000 (14:47 +0000)]
gdb: move remote arg splitting and joining into gdbsupport/
This is a refactoring commit. When passing inferior arguments to
gdbserver we have two actions that need to be performed, splitting and
joining.
On the GDB side, we take the inferior arguments, a single string, and
split the string into a list of individual arguments. These are then
sent to gdbserver over the remote protocol.
On the gdbserver side we receive the list of individual arguments and
join these back together into a single inferior argument string.
In the next commit I plan to add some unit testing for this remote
argument passing process. Ideally, for unit testing, we need the code
being tested to be located in some easily callable function, rather
than being inline at the site of use.
So in this commit I propose to move the splitting and joining logic
out into a separate file, we can then use this within GDB and
gdbserver when passing arguments between GDB and gdbserver, but we can
also call the same functions for some unit testing.
In this commit I'm not adding the unit tests, they will be added next,
so for now there should be no user visible changes after this commit.
gas: sframe: fix handling of .cfi_def_cfa_register
Fix PR gas/32879 sframe: Assembler internal error when translating
cfi_def_cfa_register
As per the documentation, .cfi_def_cfa_register modifies a rule for
computing CFA; the register is updated, but the offset remains the same.
While translating .cfi_def_cfa_register into SFrame context, we use the
information from last translated FRE to set the CFA offset. However,
there may be cases when the last translated FRE is empty. Use last FRE
only if available.
Andrew Burgess [Wed, 23 Apr 2025 09:22:32 +0000 (10:22 +0100)]
gdb/python: keyword arguments for gdb.Color.escape_sequence
GDB's Python documentation does make it clear that keywords arguments
are supported for functions that take 2 or more arguments. The
documentation makes no promise for keyword argument support on
functions that only take a single argument.
That said, I'm a fan of keyword arguments, I think they help document
the code, and make intentions clearer, even for single argument
functions.
As I'm changing gdb.Color anyway (see previous commit), I'd like to
add keyword argument support to gdb.Color.escape_sequence, even though
this is a single argument method. This should be harmless for anyone
who doesn't want to use keywords, but adds the option for those of us
that do.
I've also removed a redundant check that the 'self' argument was a
gdb.Color object; Python already ensures this is the case.
And I have folded the check that the single argument is a bool into
the gdb_PyArg_ParseTupleAndKeywords call, this means that the error
message will include the incorrect type name now, which should make
debugging issues easier.
Tests have been extended to cover both cases -- it appears the
incorrect argument type error was not previously tested, so it is
now.
Andrew Burgess [Wed, 23 Apr 2025 08:48:11 +0000 (09:48 +0100)]
gdb/doc: tweaks to documentation for gdb.Color
While reading through the documentation for the new gdb.Color class I
spotted a couple of things which I thought could be improved:
* I replaced @code{Color} with @code{gdb.Color}. Most of the other
classes are referenced with the 'gdb.' prefix, so this makes
gdb.Color consistent. Including the 'gdb.' prefix makes it far
easier to search the documentation to find relevant content. And
finally, my understanding is that usually in Python code, the
class would be written as 'gdb.Color' unless the user specifically
pulls 'Color' into the current scope using 'from gdb import
Color'.
* Replace 'colorspace' with 'color space'. There was already a use
of the two word form in the documentation (for gdb.Color), so this
just makes things consistent.
* Removed use of @var on two @defun lines. No other @defun lines
use @var, so the use of @var here was making the output
inconsistent, e.g. in the 'info' output, @var causes the string to
be capitalised.
* Rename the 'color-space' argument to 'color_space' for
Color.__init__. In the next commit I plan to add Python keyword
argument support to this function, which means the argument name
needs to be a valid keyword (i.e. must not contain the '-'
character).
* Added a pointer to where the @samp{COLORSPACE_} constants can be
found. These constants are referenced before they are defined in
the documentation, which is fine, but I think it is a good idea to
let the user know where the constants can be found when we first
reference them.
* Remove use of 'self' for the Color.escape_sequence documentation.
There are a few functions that do include 'self' as an argument (I
think this is a mistake) but the vast majority don't. I think not
including 'self' is the better approach; a user wouldn't be
expected to explicitly pass 'self', this is done automatically by
Python as a result of calling the method on an object. So I've
removed the reference to 'self' from this method.
Approved-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 22 Apr 2025 22:01:58 +0000 (23:01 +0100)]
gdb/python: don't use PyObject_IsInstance in py-unwind.c
I've been reviewing all uses of PyObject_IsInstance, and I believe
that the use of PyObject_IsInstance in py-unwind.c is not entirely
correct. The use of PyObject_IsInstance is in this code in
frame_unwind_python::sniff:
if (PyObject_IsInstance (pyo_unwind_info,
(PyObject *) &unwind_info_object_type) <= 0)
error (_("A Unwinder should return gdb.UnwindInfo instance."));
The problem is that PyObject_IsInstance can return -1 to indicate an
error, in which case a Python error will have been set. Now, the
above code appears to handle this case, it checks for '<= 0', however,
frame_unwind_python::sniff has this near the start:
gdbpy_enter enter_py (gdbarch);
And looking in python.c at 'gdbpy_enter::~gdbpy_enter ()', you'll
notice that if an error is set then the error is printed, but also, we
get a warning about an unhandled Python exception. Clearly, all
exceptions should have been handled by the time the gdbpy_enter
destructor is called.
I've added a test as part of this commit that exposes this problem,
the current output is:
(gdb) backtrace
Python Exception <class 'RuntimeError'>: error in Blah.__class__
warning: internal error: Unhandled Python exception
Python Exception <class 'gdb.error'>: A Unwinder should return gdb.UnwindInfo instance.
#0 corrupt_frame_inner () at /home/andrew/projects/binutils-gdb/build.dev-g/gdb/testsuite/../../../src.dev-g/gdb/test>
(gdb)
An additional observation is that we use PyObject_IsInstance to check
that the return value is a gdb.UnwindInfo, or a sub-class. However,
gdb.UnwindInfo lacks the Py_TPFLAGS_BASETYPE flag, and so cannot be
sub-classed. As such, PyObject_IsInstance is not really needed, we
could use PyObject_TypeCheck instead. The PyObject_TypeCheck function
only returns 0 or 1, there is no -1 error case. Switching to
PyObject_TypeCheck then, fixes the above problem.
There's a new test that exposes the problems that originally existed.
Andrew Burgess [Tue, 22 Apr 2025 20:43:43 +0000 (21:43 +0100)]
gdb/python: don't use PyObject_IsInstance in py-registers.c
In python/py-registers.c we make use of PyObject_IsInstance. The
PyObject_IsInstance can return -1 for an error, 0 for false, or 1 for
true.
In py-registers.c we treat the return value from PyObject_IsInstance
as a boolean, which means both -1 and 1 will be treated as true.
If PyObject_IsInstance returns -1 for an error, this will be treated
as true, we will then invoke undefined behaviour as the pyo_reg_id
object will be treated as a gdb.RegisterDescriptor, even though it
might not be.
I noticed that the gdb.RegisterDescriptor class does not have the
Py_TPFLAGS_BASETYPE flag, and therefore cannot be inherited from. As
such, using PyObject_IsInstance is not necessary, we can use
PyObject_TypeCheck instead. The PyObject_TypeCheck function only
returns 0 or 1, so we don't need to worry about the error case.
Because it runs so many variations, the test
gdb.dwarf2/macro-source-path.exp takes about 2:40 minutes to run for me,
in a non-optimized build. These days I often run all tests under
gdb.dwarf2, as a sanity test for my changes, and so I often have to wait
for this test to complete.
Split the test, to allow it to complete faster when running the
testsuite in parallel. After this patch, running all the
gdb.dwarf2/macro-source-path-*.exp tests in parallel takes me about 1
minute. It's more that I would expect, I would expect the time to be
divided by nearly 5, but it's already better than what we have now.
Change-Id: I07e4e1f234cf57d9b0c1c027f08061615714a4d5 Acked-By: Tom de Vries <tdevries@suse.de>
Timur [Thu, 10 Apr 2025 11:55:19 +0000 (14:55 +0300)]
gdb: fix riscv record-full push
When I (Guinevere) pushed commit b9c7eed0c2409fc640129a38d80a2bf1212b464a I accidentally used an outdated
version of the patch. This current patch fixes the importation of that
patch based on the actually approved version instead.
Tom de Vries [Wed, 23 Apr 2025 17:10:22 +0000 (19:10 +0200)]
[gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp
With a gdb 16.2 based package, I ran into:
...
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: input still accepted
interrupt
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: interrupt
set var do_wait=0
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: set var do_wait=0
continue&
Cannot execute this command while the selected thread is running.
(gdb)
Program received signal SIGINT, Interrupt.
PASS: gdb.base/bg-execution-repeat.exp: c 1&: continue&
0x00007ffff7cf1503 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6
FAIL: gdb.base/bg-execution-repeat.exp: c 1&: breakpoint hit 2 (timeout)
...
Fix this by waiting for "Program received signal SIGINT, Interrupt" after
issuing the interrupt command.
Andrew Burgess [Tue, 22 Apr 2025 18:56:13 +0000 (19:56 +0100)]
gdb/python: don't use PyObject_IsInstance in gdbpy_is_color
The gdbpy_is_color function uses PyObject_IsInstance, and converts the
return from PyObject_IsInstance to a bool.
Unfortunately, PyObject_IsInstance can return -1, 0, or 1, for error,
failure, or success respectively. When converting to a bool both -1
and 1 will convert to true.
Additionally, when PyObject_IsInstance returns -1 an error will be
set.
What this means is that, if gdbpy_is_color is called with a non
gdb.Color object, and the PyObject_IsInstance check raises an error,
then (a) GDB will continue as if the object is a gdb.Color object,
which is likely going to invoke undefined behaviour, see
gdbpy_get_color for example, and (b) when GDB eventually returns to
the Python interpreter, due to an error being set, we'll see:
Python Exception <class 'SystemError'>: PyEval_EvalFrameEx returned a result with an error set
Error occurred in Python: PyEval_EvalFrameEx returned a result with an error set
However, after the previous commit, gdb.Color can no longer be
sub-classed, this means that fixing the above problems is easy, we can
replace the PyObject_IsInstance check with a PyObject_TypeCheck, the
PyObject_TypeCheck function only returns 0 or 1, there's no -1 error
case.
It's also worth noting that PyObject_TypeCheck is the function that is
more commonly used within GDB's Python API implementation, include the
py-color.c use there were only 4 PyObject_IsInstance uses. Of the
remaining 3, 2 are fine, and one other (in py-disasm.c) is also
wrong. I'll address that in a separate patch.
There's also a new test included which exposes the above issue.
Andrew Burgess [Tue, 22 Apr 2025 17:01:07 +0000 (18:01 +0100)]
gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.Color
Remove the Py_TPFLAGS_BASETYPE flag from the gdb.Color type. This
effectively makes gdb.Color final; users can no longer create classes
that inherit from gdb.Color.
Right now I cannot think of any cases where inheritance would be
needed over composition for a simple type like gdb.Color. If I'm
wrong, then it's easy to add Py_TPFLAGS_BASETYPE back in later, this
would be an extension of the API. But it's much harder to remove the
flag later as that might break existing user code (note: there has
been no release of GDB yet that includes the gdb.Color type).
Introducing this restriction makes the next commit easier.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 22 Apr 2025 20:31:02 +0000 (21:31 +0100)]
gdb/python: stop using PyObject_IsInstance in py-disasm.c
The PyObject_IsInstance function can return -1 for errors, 0 to
indicate false, and 1 to indicate true.
I noticed in python/py-disasm.c that we treat the result of
PyObject_IsInstance as a bool. This means that if PyObject_IsInstance
returns -1, then this will be treated as true. The consequence of
this is that we will invoke undefined behaviour by treating the result
from the _print_insn call as if it was a DisassemblerResult object,
even though PyObject_IsInstance raised an error, and the result might
not be of the required type.
I could fix this by taking the -1 result into account, however,
gdb.DisassemblerResult cannot be sub-classed, the type doesn't have
the Py_TPFLAGS_BASETYPE flag. As such, we can switch to using
PyObject_TypeCheck instead, which only return 0 or 1, with no error
case.
I have also taken the opportunity to improve the error message emitted
if the result has the wrong type. Better error message make debugging
issues easier.
I've added a test which exposes the problem when using
PyObject_IsInstance, and I've updated the existing test for the
improved error message.
Commit b9c7eed0c2409fc640129a38d80a2bf1212b464a recently introduced
a build failure, because the file gdb/riscv-canonicalize-syscall-gen.c
hasn't been added to the ALL_64_TARGET_OBS variable in the makefile,
leading to a linker issue. This commit fixes that.
Also, turns out, the new file was slightly outdated, as the gdb_old_mmap
syscall has been renamed to gdb_sys_old_mmap in commit 432eca4113d5748ad284a068873455f9962b44fe. This commit also fixes that
on the generated file itself, to quickly fix the build. A followup
commit will fix the python file responsible for generating the .c file.
Guinevere Larsen [Wed, 26 Mar 2025 14:14:52 +0000 (11:14 -0300)]
GDB: Introduce "info linker-namespaces" command
Continuing to improve GDB's ability to debug linker namespaces, this
commit adds the command "info linker- namespaces". The command is
similar to "info sharedlibrary" but focused on improved readability
when the inferior has multiple linker namespaces active. This command
can be used in 2 different ways, with or without an argument.
When called without argument, the command will print the number of
namespaces, and for each active namespace, it's identifier, how many
libraries are loaded in it, and all the libraries (in a similar table to
what "info sharedlibrary" shows). As an example, this is what GDB's
output could look like:
(gdb) info linker-namespaces
There are 2 linker namespaces loaded
There are 3 libraries loaded in linker namespace [[0]]
Displaying libraries for linker namespace [[0]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7ebc000 0x00007ffff7fa2000 Yes (*) /lib64/libm.so.6
0x00007ffff7cc9000 0x00007ffff7ebc000 Yes (*) /lib64/libc.so.6
(*): Shared library is missing debugging information.
There are 4 libraries loaded in linker namespace [[1]]
Displaying libraries for linker namespace [[1]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7fb9000 0x00007ffff7fbe000 Yes gdb.base/dlmopen-ns-ids/dlmopen-lib.so
0x00007ffff7bc4000 0x00007ffff7caa000 Yes (*) /lib64/libm.so.6
0x00007ffff79d1000 0x00007ffff7bc4000 Yes (*) /lib64/libc.so.6
(*): Shared library is missing debugging information.
When called with an argument, the argument must be a namespace
identifier (either with or without the square brackets decorators). In
this situation, the command will truncate the output to only show the
relevant information for the requested namespace. For example:
(gdb) info linker-namespaces 0
There are 3 libraries loaded in linker namespace [[0]]
Displaying libraries for linker namespace [[0]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7ebc000 0x00007ffff7fa2000 Yes (*) /lib64/libm.so.6
0x00007ffff7cc9000 0x00007ffff7ebc000 Yes (*) /lib64/libc.so.6
(*): Shared library is missing debugging information.
The test gdb.base/dlmopen-ns-id.exp has been extended to test this new
command. Because some gcc and glibc defaults can change between
systems, we are not guaranteed to always have libc and libm loaded in a
namespace, so we can't guarantee the number of libraries, but the range
of the result is 2, so we can still check for glaring issues.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-by: Kevin Buettner <kevinb@redhat.com>
Guinevere Larsen [Tue, 25 Mar 2025 20:27:49 +0000 (17:27 -0300)]
gdb: factor out printing a table of solibs for info sharedlibrary
The next patch will add a new command that will print libraries in a
manner very similar to the existing "info sharedlibrary" command. To
make that patch simpler to review, this commit does the bulk of
refactoring work, since it ends up being a non-trivial diff to review.
No functional changes are expected after this commit.
projects / thirdparty / binutils-gdb.git / log
