Tom Tromey [Tue, 27 Jan 2026 03:49:26 +0000 (20:49 -0700)]
Don't use .debug_names if .debug_aranges is missing
gdb's .debug_names reader depends on .debug_aranges as well, because
if the ranges are missing, it won't be able to create a map from PC to
CU.
However, this requirement isn't enforced by gdb. I no longer recall
know why, but I can see in commit b371f07c ("Rewrite .debug_names
reader") that I made this choice on purpose:
In v1 of this patch, I made the new reader more strict about requiring
.debug_aranges. In v2, I've backed this out and kept the previous
logic. This solved a few test failures, though it's arguably not the
right approach.
However, the current setup now seems clearly incorrect to me. And, it
was causing problems for another patch I'm working on.
Fixing this required patching a few tests to add a .debug_aranges
section. I've also updated the intro comment to
read_addrmap_from_aranges to reflect how it ought to be used.
Regression tested on x86-64 Fedora 41 with both the default and the
cc-with-debug-names target boards.
Matthew Lugg [Fri, 6 Feb 2026 12:27:16 +0000 (12:27 +0000)]
gdb/dwarf2: skip unrecognised extended opcodes in line-number programs
Although the DWARF 5 specification does not outright state that
consumers should ignore unrecognised opcodes, it does make sure that
this is possible (by always encoding the length of operands), and in
fact states the following:
> The DWARF format is organized so that a consumer can skip over data
> which it does not recognize. This may allow a consumer to read and
> process files generated according to a later version of this standard
> or which contain vendor extensions, albeit possibly in a degraded
> manner.
In addition, it is mentioned in the body of DWARF Issue 180426.2 that
producers can, today, include padding bytes in line number programs by
emitting an unused extended opcode:
> In a related thread on dwarf-discuss, Cary pointed out that given how
> DWARF works, any undefined extended opcode could be used for this
> purpose. [...] consumers already know how to skip an unrecognized
> extended opcode.
Previously, if GDB encountered an unknown extended opcode in a DWARF
line number program, it would stop evaluating the program with an error.
This commit causes it to instead skip the extended opcode, leaving the
virtual machine state unmodified. As well as being supported by the
quotes above, this is consistent with GDB's *existing* handling of the
case where a *standard* LNP opcode is unrecognised.
The motivation for this change is binaries emitted by the Zig compiler,
which currently uses extended opcode 0 for padding bytes (the use case
being addressed in DWARF 6 by the DWARF issue referenced above). LLDB is
capable of parsing these line number programs, but GDB was not prior to
this commit.
Tested by running the test suite (including the added test case) and
confirming that every test which previously passed continues to pass.
Also manually tested on a binary produced by the Zig compiler, where
previously GDB was missing some line number information, but now has
complete and correct information.
Simon Marchi [Fri, 13 Feb 2026 19:17:40 +0000 (14:17 -0500)]
binutils: fix C23 -Wdiscarded-qualifiers errors
When compiling with gcc 15, I get these:
CC prdbg.o
/home/simark/src/binutils-gdb/binutils/prdbg.c: In function ‘tg_start_function’:
/home/simark/src/binutils-gdb/binutils/prdbg.c:2658:11: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
2658 | sep = strchr (name, '(');
| ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:1220: prdbg.o] Error 1
CC addr2line.o
/home/simark/src/binutils-gdb/binutils/addr2line.c: In function ‘translate_addresses’:
/home/simark/src/binutils-gdb/binutils/addr2line.c:390:21: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
390 | h = strrchr (filename, '/');
| ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:1220: addr2line.o] Error 1
CC nm.o
/home/simark/src/binutils-gdb/binutils/nm.c: In function ‘print_symname’:
/home/simark/src/binutils-gdb/binutils/nm.c:689:21: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
689 | char *atver = strchr (name, '@');
| ^~~~~~
cc1: all warnings being treated as errors
I think they are related to the fact that strchr having changed to
return const when passed a const.
Tom Tromey [Tue, 10 Feb 2026 14:47:42 +0000 (07:47 -0700)]
Handle fixed-point types in amd64_classify
gdb.ada/fixed_points_function.exp was failing when compiled with
gnat-llvm. Debugging showed that this was a gdb bug that was hidden
by differences in the DWARF generated by gcc and gnat-llvm.
In particular, gcc emitted a DW_TAG_subrange_type (a subrange of the
fixed-point type) for the function's parameter type, whereas gnat-llvm
used a fixed-point type directly.
Then, the test failed because amd64_classify recognizes subrange types
but not fixed-point types. Under the hood, fixed-point types are
really just integers, so the fix is to handle these directly in
amd64_classify.
Approved-By: Christina Schimpe <christina.schimpe@intel.com>
Simon Marchi [Mon, 26 Jan 2026 06:15:19 +0000 (01:15 -0500)]
gdb/dwarf: fix DW_OP_call{2,4} in .dwo files
Bug 31772 shows a failure of gdb.ada/finish-var-size.exp when ran with
the fission board, modified to generate DWARF 5. Ultimately, the
problem shows up when executing a DW_OP_call{2,4} operation from a .dwo
file.
The DW_OP_call{2,4} ops receive a CU-relative offset. Function
dwarf2_fetch_die_loc_cu_off receives that offset and transforms it in a
section-relative offset by adding the section offset of the containing
CU:
The problem is that `per_cu->sect_off ()` returns the offset of the
skeleton CU in the main file, when what we really want is the offset of
the split unit in the .dwo file.
To obtain that, we need to get the loaded CU (dwarf2_cu), from which we
can know if the DIEs were actually read from a .dwo file or not. And if
so, get the section offset of the dwo unit, rather than the skeleton
unit.
Calling load_cu here does not have a negative performance impact, because
it would be called by dwarf2_fetch_die_loc_sect_off anyway.
Add a section_offset method to dwarf2_cu to get the effective section
offset of the unit. This mirrors what we do for the section in
dwarf2_cu::section.
Add a test that reproduces this exact case.
GDB does not support DW_OP_call_ref, so don't test that. It would also
be unexpected anyway to have cross-unit references in a .dwo file (but
no completely unthinkable, given we support having multiple CUs in a .dwo
file).
Change-Id: If5faac252b32ed9751d29681590b668225708275
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31772 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 9 Feb 2026 19:15:00 +0000 (14:15 -0500)]
gdb: use gdb::unordered_string_map throughout
Change all uses of
gdb::unordered_map<string, T>
to
gdb::unordered_string_map<T>
Using unordered_string_map avoids constructing a temporary std::string
(possibly with dynamic allocation) when looking up values from
`const char *`.
I don't see any downsides to using unordered_string_map over
unordered_map, even if all the lookups are done using existing
std::string objects that would be built anyway.
I think there are places where we could refactor the code to avoid
constructing unnecessary std::string objects, but that is out of scope
for this patch.
There should be no change of behavior with this patch.
Change-Id: Ic4df78b97f2755d5821bb66942b9e4d9a79a3dc5 Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Mon, 9 Feb 2026 19:17:53 +0000 (14:17 -0500)]
gdbsupport: add gdb::unordered_string_map
It occurred to me that when we use a
gdb::unordered_map<std::string, T>
we construct a temporary std::string for each lookup from a
`const char *`, possibly doing dynamic allocation. This is really
unnecessary, because it's easy to compare an existing `const char *` (or
std::string_view) with an std::string. This can therefore be avoided by
having transparent hash and eq types.
Because this is a common enough case, add it to
gdbsupport/unordered_map.h, so it can easily be reused. Define the
gdb::unordered_string_map type, which uses hash and eq types that work
on std::string_view. Both `const char *` and `std::string` can
implicitly be converted to std::string_view, so this should be
sufficient.
Change-Id: Id93448d831696d25472f13c15212f13712ad8492 Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Fri, 13 Feb 2026 03:47:37 +0000 (22:47 -0500)]
gdb/elfread: add debug output for GNU ifunc resolution
Add some debug prints throughout the ifunc resolution code, to be able
to better understand what GDB does. Add the new "set debug gnu-ifunc"
knob to control it.
Add the debug_prefixed_printf_cond_func macro to implement
gnu_ifunc_debug_printf_func, that takes an explicit function name. This
is needed to avoid showing "operator()" as the function name in the
debug message.
Here is a sample session with the new debug output enabled.
(gdb) b the_function
[gnu-ifunc] elf_gnu_ifunc_resolve_name: resolving name "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolve_by_cache: resolving "the_function" by cache
[gnu-ifunc] elf_gnu_ifunc_resolve_by_cache: cache miss for "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: resolving "the_function" by GOT
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: GOT entry "the_function@got.plt" points to 0x7ffff7fb7036
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fb7036
[gnu-ifunc] elf_gnu_ifunc_record_cache: minimal symbol "the_function@plt" at 0x7ffff7fb7030 does not match addr 0x7ffff7fb7036, not caching
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: GOT entry "the_function@got.plt" points to 0x7ffff7fb2036
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fb2036
[gnu-ifunc] elf_gnu_ifunc_record_cache: minimal symbol "the_function@plt" at 0x7ffff7fb2030 does not match addr 0x7ffff7fb2036, not caching
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: failed to resolve "the_function" by GOT
[gnu-ifunc] elf_gnu_ifunc_resolve_name: failed to resolve name "the_function"
Breakpoint 2 at gnu-indirect-function resolver at 0x7ffff7fa80e9
(gdb) c
Continuing.
[gnu-ifunc] elf_gnu_ifunc_resolver_stop: stop on resolver for "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolver_stop: created resolver return breakpoint at 0x7ffff7fd7186
[gnu-ifunc] elf_gnu_ifunc_resolver_return_stop: stop on resolver return
[gnu-ifunc] elf_gnu_ifunc_resolver_return_stop: resolver for "the_function" returned resolved address=0x7ffff7fad0e9, resolved pc=0x7ffff7fad0e9
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fad0e9
[gnu-ifunc] elf_gnu_ifunc_record_cache: cached "the_function" -> 0x7ffff7fad0e9 in objfile /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/ifunc-resolver/libimpl.so
Delete the ARM sub-directory of the SIM directory.
the arm simulator was removed from the sim/ directory. GDB has now
been updated to remove its support for the arm simulator, and as a
result, this header file is no longer used by anyone. Lets delete it.
There should be no user visible changes after this commit.
gdb: fix 'info frame' for tail calls with no debug information
And playing with the test binary from that commit in the TUI.
Unlike the problem fixed by this earlier commit, the TUI status bar
function name is wrong for tail call functions both with and without
DWARF.
The problem is in the function tui_get_function_from_frame (in
tui/tui-status.c), which the TUI uses to get the function name that
will be displayed. This function calls print_address_symbolic passing
in the result of a call to get_frame_pc to get the actual function
name.
The problem is that for a tail calls, get_frame_pc will return a pc
outside the current function. Fix this by switching to use the
function get_frame_address_in_block instead.
I wanted the tests for this fix to live in gdb.tui/ as the code being
fixed is very TUI specific. As a result this does mean that the
tailcall-msym.exp test is copied from gdb.base/ (see the earlier
commit), but I don't see this as a huge problem.
There's an additional test that creates a tail call function using the
DWARF assembler, this tests the with DWARF case.
One maybe surprising change in this commit is the one to lib/gdb.exp.
This was needed because of the use of 'runto callee' in the new
tests. As we're running in TUI mode, styling will be enabled in the
output. Now most TUI tests compile "normal" .c files into an
executable with file and line debug information. As a result, when we
hit a breakpoint we see GDB output like:
Breakpoint 1, function () at file.c:25
The pattern that matches this within 'proc runto' (lib/gdb.exp)
uses '.*' to match both the function name and the filename. This
means that the styling escape sequences are also matched.
However, when building the tests added in this commit, which lack file
and line debug information, we get a breakpoint hit line like this:
Breakpoint 1, 0x000000000040110a in callee ()
The pattern in 'proc runto' that matches this uses '[0-9xa-f]*' to
match the hex address string. As a consequence, if the address is
styled, then this pattern no longer matches.
To work around this I've added an optional pattern which should match
any ansi styling escape sequence before and after the address. This
should not cause any problems for unstyled testing, but now allows
this pattern to match if styling is enabled.
Andrew Burgess [Sun, 19 Nov 2023 15:24:59 +0000 (15:24 +0000)]
gdb/gdbserver: move argument setting complexity into gdbsupport/
This commit removes some uses of gdb::argv_vec from GDB.
The gdb::argv_vec class exists in part due to our need to convert from
one container type to another in a few places, and I think by using
templates we can push this conversion down into
gdbsupport/common-inferior.{cc,h} and remove the conversion logic from
higher level code in GDB. This should make core GDB simpler.
For examples of this simplification, see python/py-inferior.c,
remote.c, and unittests/remote-arg-selftests.c, where this commit has
allowed for the removal of some code that only exists in order to
convert the container type.
Ideally I'd like to see all uses of gdb::argv_vec removed, but I'm
still not sure about the use in nat/fork-inferior.c, I think its use
there might be the best solution, so for now at least, I have no plans
to touch that code.
There should be no user visible changes after this commit.
Improve test-case gdb.testsuite/quotemeta.exp by:
- catching errors in check_quotemeta
- logging argument and results of calling quotemeta using verbose -log
- renaming quotemeta_fail to check_quotemeta_fail for consistency with
check_quotemeta
- reducing escaping using {}
- adding a missing test checking "@bad-name"
Tiezhu Yang [Sat, 31 Jan 2026 08:24:07 +0000 (16:24 +0800)]
gdb: Fix unexpected failures in breakpoint-in-ro-region.exp
Currently, there is no support for hardware breakpoints on a virtual
machine of LoongArch. When unseting CONFIG_HAVE_HW_BREAKPOINT of the
Linux kernel, there is also no support for hardware breakpoints on a
physical machine of LoongArch.
For the above cases, when executing:
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.base/breakpoint-in-ro-region.exp"
there are 4 unexpected failures:
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: thread advanced
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: thread advanced
By the way, there are no failures when executing:
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
Here are the gdb log messages if no support for hardware breakpoints:
(1) make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
```
(gdb) hbreak *0x120000628^M
No hardware breakpoint support in the target.^M
(gdb) UNSUPPORTED: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (no support)
si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) UNSUPPORTED: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region (cannot insert hw break)
```
(2) make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.base/breakpoint-in-ro-region.exp"
si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0:Remote failure reply: 01.^M
^M
(gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region
```
The outputs of "hbreak" and "si" commands are different between gdb and
gdbserver, it should check "Cannot insert hardware breakpoint" anyway.
In my opinion, this fix is not only for LoongArch but also for the other
arch that does not support hardware breakpoints. For example, if disable
CONFIG_PERF_EVENTS, then CONFIG_HAVE_HW_BREAKPOINT will be not set due to
select HAVE_HW_BREAKPOINT if PERF_EVENTS
in arch/loongarch/Kconfig of the Linux kernel code, it can reproduce the
unexpected failures.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33845 Co-developed-by: Miao Wang <shankerwangmiao@gmail.com> Signed-off-by: Miao Wang <shankerwangmiao@gmail.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: Tom Tromey <tom@tromey.com>
Tiezhu Yang [Sat, 31 Jan 2026 08:24:06 +0000 (16:24 +0800)]
gdb: Make test result accurate in breakpoint-in-ro-region.exp
Currently, if no support for hardware breakpoints, when executing:
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
the test results of "hbreak" and "si" command are "PASS":
```
(gdb) hbreak *0x120000628^M
No hardware breakpoint support in the target.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (no support)
si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region (cannot insert hw break)
```
This is not accurate, obviously it should be "UNSUPPORTED".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33845 Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 13 Feb 2026 09:19:39 +0000 (10:19 +0100)]
gprof: fix testsuite with older glibc
It is quite sad that 2.46 has again shipped with this breakage. Short of
those responsible taking care, use the workaround that was suggested in
https://sourceware.org/pipermail/binutils/2025-April/140316.html.
Jan Beulich [Fri, 13 Feb 2026 09:19:23 +0000 (10:19 +0100)]
ld: move symlink-ing of ldscripts a little earlier
Following up commit a29a6230b820 "PR 33629 ldscripts symlink in .libs/
created too late", move the symlink-ing ahead of the linking of the final
binary, to eliminate the slim chance of the build being interrupted (or
failing) at that (so far) final step. If that happened, a subsequent make
invocation with no other changes made would then not re-attempt this step.
Necessarily with this the test for the existence of the binary needs to be
removed. Perhaps that shouldn't have been there anyway, the more that the
check was lacking $(EXEEXT).
Tom Tromey [Thu, 5 Feb 2026 20:51:07 +0000 (13:51 -0700)]
Handle wide characters that cannot be converted
The internal AdaCore test suite found a bug with the char-printing
changes: on Windows, it is possible to have a wide character (in our
case, 0xBEEF) that is "printable" (as determined by iswprint) but
which cannot be converted to the current host charset.
This in turn would result in strange output like:
$2 = 48879 '\357\276'
where what we would expect in Ada would be:
$2 = 48879 '["00beef"]'
A similar problem could occur for C on Windows. There, the character
boundaries appeared lost to the user, so rather than '\xbeef' the user
would see '\357\276'.
This patch fixes this problem by checking the convertibility of a wide
character before printing it.
New in v3: Correctly check result of wcrtomb
New in v2: Skip the new check if the host encoding is UTF-8.
However, the test case is constructed so that "Center" has multiple
meanings: it might name the enumerator here:
type Posn is (Left, Center, Right);
or it might refer to this variable:
Center : Pck.Posn := Pck.Right;
The correct answer in this case is to pick the enumerator, because
that is the array's index type.
Originally I didn't fix this problem and instead used a kfail.
However, this same problem turned up again (in a slightly different
form) when the libgnat debuginfo was installed.
This patch fixes the bug by introducing new code in
ada_name_association::assign to handle the enumeration case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33896
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33898 Tested-By: Tom de Vries <tdevries@suse.de>
Jens Remus [Thu, 12 Feb 2026 12:44:01 +0000 (13:44 +0100)]
s390: Simplify linker libgot-1 tests
This applies Alan's x86 commit df865c395a62 ("libgot-1 testcases")
simplifications to the respective s390 linker tests. With Alan's words:
There is no need for multiple tests of readelf --got-contents,
nor should the matching be so strict that changes in section layout
force editing of the testsuite.
ld/testsuite/
* ld-s390/binutils.exp (libgot-1*): Reduce number of tests.
* ld-s390/libgot_64-1.rd: New test.
* ld-s390/libgot_64-1a.rd: Remove.
* ld-s390/libgot_64-1b.rd: Likewise.
* ld-s390/libgot_64-1c.rd: Likewise.
* ld-s390/libgot_64-1d.rd: Likewise.
Tom Tromey [Thu, 5 Feb 2026 18:17:22 +0000 (11:17 -0700)]
Fix copyright dates for new files
I forgot to add 2026 to a copyright date in a file I recently
committed (but had originally submitted in 2025). Thinking this might
have happened before, I re-ran gdb/copyright.py and it pointed out a
surprising number of such changes.
Tom Tromey [Fri, 21 Sep 2018 15:46:35 +0000 (09:46 -0600)]
Add .clang-format
This patch adds a .clang-format file to the gdb repository.
The resulting reformatting is what I'd describe as "ok but not great".
There are a few variances from our normal style, some discussed in
comments in the file, and some in the bug.
I've somewhat come around to the idea that some ugliness is
acceptable, particularly because I regularly see code that's already
ugly anyway -- either in formatting or along some other dimension.
I don't know of a way to enforce a particular version. I have only
tried clang-format 18 with this particular file, though Kevin Buettner
reported trying 19-21 as well. I've documented this in the file.
I used "AllowShortFunctionsOnASingleLine: InlineOnly" as previously
discussed. I feel that the spirit of the GNU style is that vertical
space is free, and we should use "None" here. (This goes against
something we previously decided on the list, though.)
The file is in the root directory for ease of use.
For the time being you should not bulk reformat files. I think we
should have a flag day for this, but at some later point. See the
earlier discussion for details.
New in v4:
* Comment fixes
* Remove ForEachMacros - no longer correct
* Remove IncludeCategories - no longer correct
New in v5:
* More fixes to the comments
New in v6:
* Removed 'StatementMacros' setting, we're no longer using
PyObject_HEAD
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30098 Approved-by: Kevin Buettner <kevinb@redhat.com>
This commit introduced a non backward compatible change to how GDB
handled skip files. Something like:
skip -gfile dir/*.c
no longer matches every file within 'dir/', but now matches every file
in 'dir/' and within every sub-directory of 'dir/', which might not be
what the user wanted.
The original intention behind the commit is solid, we just need to
find a better implementation.
(gdb) bt
#0 0x00000001000008d4 in main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.opt/empty-inline-cxx.cc:63
(gdb) FAIL: gdb.opt/empty-inline-cxx.exp: opt_level=Og: backtrace in main
This is almost correct, except the test is not expecting the
"0x00000001000008d4 in" part. This first backtrace is done
immediately after the 'runto_main' call so the fact that we're not
stopped exactly at the start of line 63 is a little strange, but isn't
a critical part of this test. As such I've updated the test pattern
to accept an optional address within the backtrace.
This failure was brought to my attention in this mailing list post:
Alan Modra [Wed, 11 Feb 2026 05:01:33 +0000 (15:31 +1030)]
Free sframe encoder context
Like the patch to free sframe decoder data, this also needs to ensure
the function doing the free is passed the actual context address.
bfd/
* elf-sframe.c (_bfd_elf_write_section_sframe): Don't pass
address of local var to sframe_encoder_free, pass the actual
context address.
* elf64-s390.c (elf_s390_link_hash_table_free): New function.
(elf_s390_link_hash_table_create): Set hash_table_free. Tidy
zmalloc call.
(_bfd_s390_elf_write_sframe_plt): Don't pass address of local
var to sframe_encoder_free, pass the actual context address.
* elflink.c: Include sframe-api.h.
(_bfd_elf_link_hash_table_free): Free sframe encoder data.
* elfxx-x86.c (elf_x86_link_hash_table_free): Likewise.
(_bfd_x86_elf_write_sframe_plt): Don't pass address of local
var to sframe_encoder_free, pass the actual context address.
libsframe/
* sframe.c (sframe_encode): Free context on error return path.
Alan Modra [Wed, 11 Feb 2026 05:00:40 +0000 (15:30 +1030)]
Free sframe context memory on bfd_close
Call sframe_decoder_free in _bfd_elf_free_cached_info and correct
other calls to sframe_decoder_free so that sfd_info->stf_ctx is
cleared. If sfd_info->stf_ctx isn't cleared we get double frees.
* elf-sframe.c (sframe_decode): Do not pass local var sfd_ctx
address to sframe_decoder_free, pass the actual context address.
(_bfd_elf_merge_section_sframe): Likewise.
* elf.c: Include sframe-api.h.
(_bfd_elf_free_cached_info): Free sframe info.
Alan Modra [Wed, 11 Feb 2026 05:00:24 +0000 (15:30 +1030)]
Double-free sframe_decode tempbuf
If an error occurs after assigning tempbuf to dctx->sfd_buf, then
tempbuf will be freed twice. Avoid that by moving tempbuf and its
free on errors into the block where it is used.
Jan Vrany [Tue, 10 Feb 2026 19:30:03 +0000 (19:30 +0000)]
gdb/testsuite: remove timeout setting from gdb.base/chng-syms.exp
Test gdb.base/chng-syms.exp sets timeout to 10 seconds unconditionally.
Not only this is not necessary as the default timeout seems to be the
same, it may actually lower the timeout if set in site.exp (which is
the common technique to setup testsuite on slow machines).
Simon Marchi [Mon, 9 Feb 2026 21:27:04 +0000 (16:27 -0500)]
gdb/testsuite: do not force -static in gdb.ada/mi_ex_cond.exp
When running gdb.ada/mi_ex_cond.exp on Debian 13, I get:
-catch-exception -c "i = 2" -e constraint_error
^error,msg="Your Ada runtime appears to be missing some debugging information.\nCannot insert Ada exception catchpoint in this configuration."
(gdb)
FAIL: gdb.ada/mi_ex_cond.exp: catch C_E if i = 2 (unexpected output)
And this is despite having the check "gnat_runtime_has_debug_info" at
the top of the file.
The problem is that the "gnat_runtime_has_debug_info" is done using the
toolchain's default mode, regarding linking to a static or shared
libgnat. On Debian, the default is specificalyl changed to be shared
[1].
However, the test forces linking to a static libgnat. The result is
that gnat_runtime_has_debug_info passes, seeing that when linking
against libgnat.so, debug info is available (distributed as separate
debug info, in /usr/lib/debug). But then, the test explicitly builds
against a static libgnat, and then fails because debug info is not
found.
I propose to remove that "force static" part of the test. It was added
in the test in the original commit that introduced it [2] without
explanation. Not forcing it makes more sense to me:
gnat_runtime_has_debug_info checks if, when using the default linking
mode of the toolchain, debug info can be found. And then, not
specifying anything to gdb_compile_ada builds the test binary with the
default mode of the toolchain. So the two are coherent.
With this patch, I see the failures shown by Tom Tromey in this patch
[3], and with his patch applied, the test passes fine.
Tom Tromey [Mon, 9 Feb 2026 19:17:17 +0000 (12:17 -0700)]
Minor Ada test fix for gnat-llvm
gdb.ada/char_enum_overload.exp fails because LLVM optimizes away the
necessary function parameters. Adding a couple of calls to Do_Nothing
makes this test work.
aarch64: Add the missing tests for TLBI <operation> vmallws2e1
In the support for FEAT_TLBID feature patch, few <operation>
variants are added to the aarch64_sys_regs_tlbi table,
and that patch was missing the tests for following <operation>
variants, which are covered in this patch.
Alan Modra [Tue, 10 Feb 2026 00:16:47 +0000 (10:46 +1030)]
tidy elf attr error handling
Add a missing error check, and make another error check a little more
stringent. If it were ever possible for oav2_parse_attr to return
zero, the loop would not terminate.
* elf-attrs.c (oav2_parse_subsection): Check read_ntbs return
for errors. Tidy loop reading attrs, and error on <= 0.
Alan Modra [Tue, 10 Feb 2026 00:04:48 +0000 (10:34 +1030)]
PR 33858 Object Attributes v2 memory leaks
It is possble for elf_object_p to hit errors after or during the loop
processing sections with bfd_section_from_shdr. That means we might
have some object attributes malloc'd. They need cleaning up in
elf_object_p because bfd_check_format_matches only handles tidying of
bfd_alloc memory.
* elfcode.h (elf_object_p): Free object attributes on failure.
Tom Tromey [Mon, 9 Feb 2026 03:52:04 +0000 (20:52 -0700)]
Fix gdb.ada/mi_ex_cond.exp when libgnat debuginfo is installed
When libgnat debuginfo is installed, gdb.ada/mi_ex_cond.exp will fail.
I tracked this down to two problems:
1. The MI output has changed a little. This probably wasn't noticed
because this test only works when libgnat debuginfo is available,
which isn't the norm. This patch updates the expected output.
2. The variable "I" in the test triggers the Ada disambiguation menu,
because some variables named "I" are visible in libgnat. While at
its root this is a deeper problem in the Ada support, it's
complicated to fix this. Since this isn't the point of the test,
this patch just renames the variable in question.
There are some other Ada tests that fail in this setup, but I think
they are a bit more complicated to fix.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Sun, 8 Feb 2026 22:04:11 +0000 (17:04 -0500)]
gdb/registry: add registry::key::try_emplace
We have many times the pattern:
current_source_location *loc
= current_source_key.get (pspace);
if (loc == nullptr)
loc = current_source_key.emplace (pspace);
return loc;
I thought it would be nice to have it directly part of registry::key.
Add a try_emplace method, which is like emplace, except that it returns
the existing data, if any. The try_emplace name comes from similar
methods in std::map or gdb::unordered_map
(ankerl::unordered_dense::map).
Replace as many callers as I could find to use it.
Change-Id: I21f922ca065a354f041caaf70484d6cfbcbb76ed Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sun, 8 Feb 2026 22:04:10 +0000 (17:04 -0500)]
gdb/registry: make registry::key::emplace return a reference
Since we use C++ and not C, I think that we should gradually move to
using references for things that can never be nullptr. One example of
this is the return value of the emplace method.
Change it to return a reference, and (to keep the patch straightforward)
update all callers to take the address. More patches could follow to
propagate the use of references further.
Change-Id: I725539694cf496f8288918cc29d7aaae9aca2292 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sun, 8 Feb 2026 22:04:09 +0000 (17:04 -0500)]
gdb/guile: wrap scm-arch.c per-arch data in a structure
scm-arch.c uses "void" as a registry data type here:
/* Use a 'void *' here because it isn't guaranteed that SCM is a
pointer. */
static const registry<gdbarch>::key<void, gdb::noop_deleter<void>>
arch_object_data;
This conflicts with my subsequent patch that makes the emplace method
return a reference because it's not valid to have `void &`.
Circumvent the problem by defining a structure type to use in the
registry, instead of storing the SCM directly. I think that makes the
code more straightforward and less hacky anyway (at the cost of one
extra allocate per gdbarch that you would use in your Guile code...).
Change-Id: I8d92234a9b0384098fa066dc79a42195dee7ca04 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 16 Jan 2026 16:19:09 +0000 (09:19 -0700)]
Use std::make_unique with ui_files
This changes a couple of spots to use std::make_unique rather than
'new'. This is a bit more idiomatic. I've only touched code
involving ui_file here, there are plenty more changes like this that
could be made, but I considered those unrelated to this series.
Tom Tromey [Wed, 10 Dec 2025 09:24:13 +0000 (02:24 -0700)]
Warn if log file changed while logging
PR gdb/33531 points out that while some "set logging" commands will
warn if you attempt to change settings when logging is already active,
"set logging file" does not. This patch corrects this oversight.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33531 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sat, 6 Dec 2025 21:12:37 +0000 (15:12 -0600)]
Rewrite output redirection and logging
This patch changes how gdb output redirection is done.
Currently, output is done via the UI. gdb_stdout, for example, is a
define the expands to an lvalue referencing a field in the current UI.
When redirecting, this field may temporarily be reset; and when
logging is enabled or disabled, this is also done.
This has lead to bugs where the combination of redirection and logging
results in use-after-free. Crashes are readily observable; see the
new test cases.
This patch upends this. Now, gdb_stdout is simply an rvalue, and
refers to the current interpreter. The interpreter provides ui_files
that do whatever rewriting is needed (mostly for MI); then output is
forward to the current UI via an indirection (see the new
ui::passthrough_file).
The ui provides paging, logging, timestamps, and the final stream that
writes to an actual file descriptor.
Redirection is handled at the ui layer. Rather than changing the
output pipeline, new ui_files are simply swapped in by rewriting
pointers, hopefully with a scoped_restore.
Redirecting at the ui layer means that interpreter rewriting is still
applied when capturing output. This fixes one of the reported bugs.
Not changing the pipeline means that the problems with the combination
of redirect and logging simply vanish. Logging just changes a flag
and doesn't involve object destruction.
Tom Tromey [Sat, 6 Dec 2025 21:35:24 +0000 (15:35 -0600)]
Add a new logging_file implementation
This adds a new logging_file subclass of ui_file. This new subclass
handles the details of logging, by consulting the relevant globals.
I think a dependency on globals is warranted here, because the logging
settings themselves are global.
The idea of this approach is that rather than modifying the output
pipeline in response to logging commands, a logging_file will simply
always be in the pipeline, and will then react to the appropriate
settings. ("Appropriate" because there are tests that the logger
doesn't immediately react to changes, so it captures settings at the
moment logging starts.)
The new code isn't actually used yet -- nothing in this patch
constructs a logging_file. It's separate for easier review.
Tom Tromey [Tue, 9 Dec 2025 15:38:30 +0000 (08:38 -0700)]
Remove m_applied_style from ui_file
While working on this series, I found a number of odd styling issues
recurred. For instance, the issue where the pager would lose track
and style subsequent output incorrectly reappeared.
It turned out that different ui_file objects in the output pipeline
would get confused about their current style. And, looking deeper at
this, I realized that mainly it is the pager that really needs to
track the current style at all. All the other file implementations
can be purely reactive (except the buffered stream code, as Andrew
pointed out).
This patch moves m_applied_style from ui_file and into pager_file.
This necessitated making ui_file::vprintf virtual, so that the base
class could pass in the "plain" style as the starting point, whereas
the pager could use the applied style. (I did not investigate whether
this was truly necessary, and I somewhat suspect it might not be.)
This straightforward approach caused some regressions, mostly
involving extra ANSI escapes being emitted. I fixed most of these by
arranging for ui_out::call_do_message to track styles a little more
thoroughly.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Thu, 11 Dec 2025 22:12:30 +0000 (15:12 -0700)]
Rewrite cli-style.c:do_show
IMO it looks a little nicer if cli-style.c:do_show uses a single
printf to display its output. This is also slightly more
i18-friendly.
I noticed this while debugging a case where multiple redundant ANSI
escapes were sent. In conjunction with a subsequent patch, this
approach happens to fix that problem. FWIW I don't consider such
redundancies to be bugs, but it was convenient to change this one.
Tom Tromey [Tue, 9 Dec 2025 16:37:26 +0000 (09:37 -0700)]
Restore ui_file::can_page
A while back, I removed the ui_file::can_page method. It wasn't
needed for a while, due to how output redirections were done.
With the new approach in this series, it's convenient to have this
method again, because the pipeline downstream from the pager won't
change when logging -- the logging filter will be enabled or disabled
without reconfiguring the pipeline. This method lets the pager adapt
correctly.
Tom Tromey [Sat, 17 Jan 2026 16:09:22 +0000 (09:09 -0700)]
Remove gdb_stdtargin
gdb_stdtargin is only used in a single place; and, strangely, does not
follow the current UI. This patch removes the global and changes the
one user to use gdb_stdin instead.
Tom Tromey [Sun, 7 Dec 2025 00:55:20 +0000 (18:55 -0600)]
Move buffered stream to new files
The buffered stream code is currently in ui-out.h and ui-out.c, which
seems weird because it seems more like a low-level ui-file idea (for
the most part, it does also affect some ui_out).
This patch moves the declarations to a new header file,
buffered-streams.h and the implementation to buffered-streams.c. This
seems cleaner to me.
Tom Tromey [Sun, 7 Dec 2025 23:29:17 +0000 (17:29 -0600)]
Move stdtarg to ui
Currently, most of the output streams are handled by the UI -- with
the sole exception of gdb_stdtarg. This doesn't make sense to me, and
it is is useful in the longer term to make it per-UI so that the
logging approach can be uniform across all streams. So, this moves it
to the UI, following the implementation approach of all other output
streams.
Tom Tromey [Mon, 9 Feb 2026 14:33:59 +0000 (07:33 -0700)]
Remove unused local variable from c_type_print_base_struct_union
In my earlier patch to remove TYPE_FN_FIELD_STUB, I didn't notice that
the local variable mangled_name_holder is now unused and can be
removed. The compiler didn't notice, either, I assume because it has
a constructor and destructor.
The commit causes regressions in 15 test-cases (x86_64-linux, openSUSE
Leap 16.0).
I investigated one regression, in test-case gdb.base/condbreak-call-false.exp,
and in that case glibc debuginfo was required to reproduce the regression.
It's not necessary to link with mold nor to build with -O0 to reproduce
the error, but it makes the error message more informative regarding
which use of std::atomic requires the __atomic_compare_exchange symbol.
For some reason, the compare_exchange_strong calls on
`std::atomic<packed<dwarf_source_language, 2>>` added in 329a53a6d5 make
clang generate a call into libatomic, whereas gcc implements it using
only the generated assembly. I'm no compiler expert, but this seems
like a choice that each compiler is free to make. The solution is to
use the -latomic flag when linking in clang builds.
We (the ROCgdb team) considered writing a targeted configure check to
determine if -latomic was needed for this specific edge case, for the
toolchain in use. But we ended up thinking it would be simpler to just
always link with libatomic, when it is present. We think there is no
real downside to it. If libatomic is not really needed, since most
toolchains now default to using --as-needed, libatomic won't be
DT_NEEDED if it's not truly needed. Plus, if things change (either our
code or the compilers) in the future and more things end up requiring
libatomic, we'll be covered.
Bug 33879 is about the error shown above. Bug 29455 appears to be the
same, but about symbol __atomic_load.
Change-Id: I6778ae8f35acc99ffb8955479bb57766eecf4556
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33879
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29455 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 21 Jan 2026 19:27:44 +0000 (12:27 -0700)]
Mark some gdbarch components as "unused"
This adds a new "unused" attribute to gdbarch components, and marks a
few this way. The only goal of this patch is to make it so that
check-gdbarch.py gives an empty report by default.
Tom Tromey [Mon, 4 Nov 2024 20:56:48 +0000 (13:56 -0700)]
Remove the auto_charset gdbarch hook
The auto_charset gdbarch hook has never been set by any architecture.
I probably added it (don't remember) to be parallel to
auto_wide_charset -- but considering that it hasn't ever been needed,
it seems fine to remove it.
Tom Tromey [Mon, 4 Nov 2024 07:51:16 +0000 (00:51 -0700)]
Use 'invalid' rather than 'predicate' in some gdbarch functions
The check-gdbarch.py script points out that a few gdbarch functions
have a predicate that is never called. This patch changes these
functions to use 'invalid=False' instead, removing a bit of code.
Tom Tromey [Sat, 2 Nov 2024 17:36:45 +0000 (11:36 -0600)]
Add check-gdbarch.py
This adds a new check-gdbarch.py script. This script checks the
sources to see which gdbarch methods are set but never called, and
which ones are called but never set.
This uses Pygments to scan the sources, to ensure we don't
accidentally pick up gdbarch references from comments (or, less
likely, strings). Because this is pretty slow, it also uses "tqdm" to
show a progress bar. (You can "pip install tqdm" to get this.)
Tom Tromey [Tue, 13 May 2025 23:53:27 +0000 (17:53 -0600)]
Remove best_symbol and better_symbol
This patch removes best_symbol and better_symbol.
Before some c-exp.y changes this year, best_symbol was the source of
excess CU expansion, because searches that include SEARCH_VAR_DOMAIN
will keep going until a symbol is found in that domain, or until all
matches have been exhausted. So, for instance a "SEARCH_VFT" search
for "int" will, most likely, expand all CUs -- even though the
argument implies that a type would be suitable.
Nowadays, best_symbol is more of an aesthetic offense and abstraction
violation, encoding a workaround for a C++ expression lookup bug into
a low-level lookup function.
This patch changes the the C parser to simply do two lookups,
prioritizing SEARCH_VAR_DOMAIN. This way, it gets the result it is
presumably looking for, without causing excessive expansion (if that's
currently possible) and without pushing its requirements into generic
code.
Note that the special case for "stub" symbols remains. This one is
less problematic, at least for the time being, as such symbols aren't
common. (Kevin does have a patch pending in this area but I don't
believe this change should affect it, as the stub symbol case remains
unchanged.)
New in v2: addressed review comments and reworded the commit text.
v1 is here:
Indu Bhagat [Fri, 6 Feb 2026 20:21:34 +0000 (12:21 -0800)]
objdump: sframe: fix multiple emission of SFrame and DWARF Frame
Currently, when a user specifies both -WF (to dump DWARF Frame) and
--sframe, the dump_dwarf () call is triggered twice,
First, in dump_bfd ():
if (dump_dwarf_section_info)
dump_dwarf (abfd, is_mainfile);
And then again in dump_bfd () via:
if (dump_sframe_section_info)
dump_sframe_section (abfd, dump_sframe_section_name, is_mainfile);
Where dump_sframe_section () itself invokes dump_dwarf () to emit SFrame
section.
The original intent of making dump_sframe_section () to invoke
dump_dwarf () was to reuse the existing (DWARF) machinery for relocation
and emission of SFrame section (along with DWARF sections). But this
may cause duplicate emission as noted above (PR 33806).
So, carve out the necessary work into dump_sframe_section () to make it
not invoke dump_dwarf (): explicitly load the SFrame section and then
invoke the associated display function directly. This ensures that the
SFrame textual dump is emitted exactly once as intended.
Additionally, this patch removes:
- the temporary "sframe-internal-only" debug option because it not
needed anymore, now that we dont use dump_dwarf () for SFrame dumping
anymore.
- stubs from dump_dwarf_section () specific to SFrame, as it is not
called for it anymore.
While at it, xstrdup consistently and free the dump_sframe_section_name
var.
Update the existing sframe-func.s to ensure .eh_frame section is emitted
as well. Add new test objdump-sframe-2.d to verify that textual dump
using objdump contains single textual dumps of .eh_frame and .sframe (if
both --sframe and -WF are specified).
PR libsframe/33806
binutils/
PR libsframe/33806
* dwarf.c (debug_option_table): Remove sframe-internal-only.
* objdump.c (dump_sframe_section): Call display function
directly instead of dump_dwarf.
(dump_bfd): Update call to dump_sframe_section.
(main): Remove 'sframe-internal-only' hack.
binutils/testsuite/
* binutils-all/x86-64/sframe-func.s: Emit .eh_frame section as
well.
* binutils-all/x86-64/objdump-sframe-2.d: New test.
projects / thirdparty / binutils-gdb.git / log
