Simon Marchi [Fri, 20 Feb 2026 14:52:14 +0000 (09:52 -0500)]
gdb/testsuite: fix gdb.base/maint.exp odd test name
I noticed this odd test name:
PASS: gdb.base/maint.exp: maint currently expandedinfo currently expandedline-table currently expandedwith currently expandedfilename currently expandedof currently expandedsymtab currently expandedthat currently expandedis currently expandednot
This is because the join TCL proc is misused. It ends up joining all of
the words in
"maint info line-table with filename of symtab that is not"
with the string
" currently expanded"
when the intention was to concatenate.
Change it back to just a plain string. We can have a debate over this,
but in my opinion it's more readable to have the plain string (even if
the line is a bit long) instead of building the test name by
concatenating parts. It's also more grep-able.
Change-Id: I491eb6843deed1c1b6edf0ebf9161644f0894b5a Approved-By: Tom de Vries <tdevries@suse.de>
Simon Marchi [Tue, 17 Feb 2026 21:16:44 +0000 (16:16 -0500)]
gdb/solib-frv: remove manual memory management
- Make fetch_loadmap return a unique pointer, adjust callers
- Make fetch_loadmap use a unique pointer for ext_ldmbuf
- Replace some fields of lm_info_frv to be unique pointers
- Make main_executable_lm_info a unique pointer
I can only build-test this.
Change-Id: I5782ea31b5e30fef2c7468f0bc24d10ffae92669 Approved-by: Kevin Buettner <kevinb@redhat.com>
PR ld/24600: LD: Add support for file collections as artificial archives
Implement linker support for `--start-lib' and `--end-lib' command-line
options and an analogous LIB linker script statement for treating a list
of object files as members of an artificial archive. This is built upon
BFD's fake archive feature, to support the same command-line options of
the GOLD linker being phased out.
Usual archive semantics is preserved for such artificial archives, such
as symbol resolution rules, archive grouping, and the `--whole-archive'
feature, except for the `--no-link-mapless' setting which is ignored as
meaningless for such loose file collections which cannot have a symbol
map.
There is no support for nested archives or other members that are not
object files, e.g. if a file supplied as a member archive is a linker
script, it will be silently ignored, just as with actual archives. It
is unlike with input files passed that are not members of an artificial
archive.
Update documentation and expand test coverage accordingly.
PR ld/24600: BFD: Add general linker support for fake archives
Add support to BFD for file collections pretending to be archives, with
the usual linker symbol resolution semantics as with actual archives.
This is an underlying feature to implement `--start-lib'/`--end-lib'
group support of the GOLD linker being phased out.
It comes in the form of `bfd_openr_fake_archive' function which arranges
for a list of input files supplied to be treated as an archive, with
`bfd_openr_next_archived_file' then referring to successive elements of
the list previously supplied.
Use the BFD pointer member of the first file and proxy handle members of
`struct bfd' and `struct artdata' respectively to hold references to the
members of such an artificial archive once arranged. Such an archive
has to be a mapless one necessarily and any use will require a symbol
index to be produced on the fly.
Add assertions throughout backend code that is supposed not to be ever
reached in the handling of such archives and which continues to use the
first file and proxy handle members of `struct bfd' and `struct artdata'
solely to keep offsets into the owning archive file.
BFD: Add BFD pointer member to archive member references
In preparation for the next change replace a file offset with a union
of one and a BFD pointer in `struct bfd' and `struct artdata' members
used to refer to archive members and rename the members accordingly.
No functional change at this point.
Calls to `new_afile' can in principle return a NULL pointer. However
in `lookup_name' we dereference the pointer returned without validating
it first. Since it's not supposed to be NULL there except where we have
hit an internal consistency issue just add an assertion for meaningful
output rather than just a segfault.
For consistency update `cmdline_load_object_only_section' replacing a
call to `abort' with the same assertion.
PR ld/24600: LD: Add options to control mapless archive acceptance
Add `--link-mapless' and `--no-link-mapless' LD command-line options, to
respectively enable and disable the acceptance of mapless archives on a
per-file basis, also with XCOFF targets, enabled by default. Update
documentation and add test cases accordingly.
PR ld/24600: BFD: Add general linker support for mapless archives
Expand linker mapless archive support from XCOFF targets only across the
remaining ones, except for VMS targets whose archive format always has a
symbol map. For this tranform BFD code used by AR to produce symbol
maps to archive files such as to have a handler supplied to either write
a map to a file or convert symbol data to an archive symbol definition
table attached to an archive BFD as if read from a symbol map, but using
pointers to member BFDs rather than file offsets. Retain XCOFF handling
code as it is.
Where the archive group feature is used a given archive may be opened
multiple times in a single link. If this happens then a reference to a
symbol the definition of which is provided by said archive will change
from undefined on the first access to the archive to defined on later
accesses. The symbol table is pulled from an archive only for undefined
references, so if a symbol table has been pulled on first access and
then dropped by on-the-fly symbol map generation on a subsequent access,
then the symbol table is never re-read. Later on when the linker wants
to access it to actually resolve symbol references it won't have been
reloaded and a crash would happen on a null pointer dereference.
To prevent this from happening add code to `_bfd_compute_and_push_armap'
to let the caller request the symbol table to be retained and ask for it
when building a symbol map on the fly in the linker. The symbol table
will likely be used further down the link anyway.
Additionally always check the format of the first member of an archive,
even if no symbol map is present, and respect the format determined, so
that the correct format is used even if it is not the default one the LD
has been configured for, preventing segmentation faults from triggering
in `cris-aout' LD with the default (`crisaout') emulation or with the
`criself' emulation explicitly requested where archive members are in
the ELF format and consequntly removing failures with new tests:
cris-aout -FAIL: CRIS regular archive w/o index link (explicit emulation)
cris-aout -FAIL: CRIS regular archive w/o index link (implicit emulation)
cris-aout -FAIL: CRIS thin archive w/o index link (explicit emulation)
cris-aout -FAIL: CRIS thin archive w/o index link (implicit emulation)
Update documentation and adjust test cases accordingly now that mapless
archives are accepted for link by all targets except for VMS ones, which
never produce them in the first place.
Replace the file offset with a union of one and a BFD pointer in `struct
carsym', as a preparation to handle symbol maps built on the fly rather
than fetched from a file. No functional change.
NB there's a note on `struct carsym' being a type pun on `struct symdef'
as in include/aout/ranlib.h (or `struct ranlib'; no idea where it comes
from). It is possibly not true anymore, even more so with this code
update in place, depending on the underlying type of `file_ptr'. This
is not a problem however, because we always process `struct carsym' data
by hand and only use it internally rather than reading/writing from/to a
file. Therefore remove the note, as no longer applicable.
We seem to be quite lax in flipping between signed and unsigned file
offsets in archive handling. As member positions within an archive
cannot be negative it makes little to no sense to keep such values in
structures, as their existence is supposed to be transient only where a
function call returns one to indicate a failure. Such failures need to
be handled appropriately of course, but there's no point in storing the
error indicator as a symbol location reference.
Switch the data type for the file offset embedded in the archive symbol
structure from signed to unsigned then, in preparation to unify archive
location references with a later change. Update code where necessary
accordingly. No functional change.
Alan Modra [Fri, 20 Feb 2026 17:29:50 +0000 (17:29 +0000)]
BFD: Correct archive format determination for non-default link emulations
Fix an issue with archive format determination coming from commit b228303dd14e ("PR binutils/13278: --plugin doesn't work on archive"),
<https://inbox.sourceware.org/binutils/20111011064345.GM25970@bubble.grove.modra.org/>,
causing the default link emulation to be used despite archive members
being in another object format and consequently triggering segmentation
faults in `cris-aout' LD with the default (`crisaout') emulation where
archive members are in the ELF format.
Address the issue by always checking the format of the first member of
an archive even if no default target has been specified, except when the
target being checked against is be the plugin target. Verified by hand
and the `powerpc64le-linux-gnu' target to cause no issue with the recipe
in PR binutils/13278 and removing failures from segmentation faults with
the new tests:
cris-aout -FAIL: CRIS regular archive link (implicit emulation)
cris-aout -FAIL: CRIS thin archive link (implicit emulation)
Co-Authored-By: Maciej W. Rozycki <macro@redhat.com>
BFD/aout: Sanitize back end flavour for external symbols retrieval
Make `aout_get_external_symbols' return unsuccessfully right away if
called for a non-aout BFD, preventing a crash from an attempt to access
inexistent ->tdata.aout_data->a (`struct aoutdata') struct member. Add
assertions at call sites to track potential invalid usage.
This converts a segmentation fault to an assertion failure followed by
graceful termination:
.../ld/ld-new: BFD (GNU Binutils) 2.45.50.20251209 assertion fail .../bfd/aoutx.h:3449
.../ld/ld-new: tmpdir/ab.a: error adding symbols: file in wrong format
with an upcoming test case:
FAIL: CRIS regular archive link (implicit emulation)
BFD: Unset the format on releasing a BFD's objalloc memory
Make a BFD reusable after a `_bfd_free_cached_info' call to release its
objalloc memory, by unsetting the format so that a subsequent call to
`bfd_check_format_matches' will re-retrieve data previously discarded.
Otherwise accesses to discarded data will be attempted where the BFD
continues being used. Found with a crash in `bfd_set_gp_size' when
building archive symbol maps on the fly in a subsequent change.
Tom de Vries [Fri, 20 Feb 2026 11:21:05 +0000 (12:21 +0100)]
[gdb] Handle pagination prompt during posted event
PR python/24796 reports the following problem.
We have a python file test.py:
...
import gdb
def Event():
for x in range(0, 10):
print("Line")
gdb.post_event(Event)
...
Without pagination, we simple have:
...
(gdb) source test.py
(gdb) Line
Line
...
Line
Line
print 1
$1 = 1
(gdb)
...
But with pagination (and height set to 8), we get instead:
...
(gdb) source test.py
(gdb) Line
Line
...
Line
--Type <RET> for more, q to quit, c to continue without paging--c
Line
Line
Line
print 1
readline: readline_callback_read_char() called with no handler!
What leads to the crash, is that this code in gdb_readline_wrapper_line:
...
/* Prevent parts of the prompt from being redisplayed if annotations
are enabled, and readline's state getting out of sync. We'll
reinstall the callback handler, which puts the terminal in raw
mode (or in readline lingo, in prepped state), when we're next
ready to process user input, either in display_gdb_prompt, or if
we're handling an asynchronous target event and running in the
background, just before returning to the event loop to process
further input (or more target events). */
if (current_ui->command_editing)
gdb_rl_callback_handler_remove ();
...
when activated by the pagination prompt removes the callback handler (which
sets rl_linefunc to NULL).
The comment mentions re-installing the callback handler, but that doesn't
happen, so when calling rl_callback_read_char we run into:
...
if (rl_linefunc == NULL)
{
_rl_errmsg ("readline_callback_read_char() called with no handler!");
abort ();
}
...
An example of re-installation is found here in infrun.c:
...
/* Cleanup that reinstalls the readline callback handler, if the
target is running in the background. If while handling the target
event something triggered a secondary prompt, like e.g., a
pagination prompt, we'll have removed the callback handler (see
gdb_readline_wrapper_line). Need to do this as we go back to the
event loop, ready to process further input. Note this has no
effect if the handler hasn't actually been removed, because calling
rl_callback_handler_install resets the line buffer, thus losing
input. */
Jan Beulich [Fri, 20 Feb 2026 07:36:55 +0000 (08:36 +0100)]
gas: tighten get_single_number()
Move what the function does closer to what its name says. Add some error
checking, also in its sole caller (implementing entirely undocumented and
- so far - entirely untested behavior).
I really want the -f passed to gas in the new testcase, yet that means the
odd-looking .if expression can't be commented upon
("NUMBERS_WITH_SUFFIX implies in particular no C-style octal numbers").
Jan Beulich [Fri, 20 Feb 2026 07:35:41 +0000 (08:35 +0100)]
gas/z80: adjust .assume handling
get_single_number() is (bogusly) more similar to get_absolute_expression()
than its name says. As (per documentation) an expression is wanted here,
use the respective function, which then also adds at least a little bit of
error checking.
While there also deal with possible stray other stuff on the line, as
appropriate.
Andrew Burgess [Thu, 12 Feb 2026 18:22:50 +0000 (18:22 +0000)]
gdb/testsuite: update C++ tests for volatile changes in C++20
I ran the testsuite on a machine where the C++ compiler was C++20 by
default, and noticed a bunch of errors like this:
gdb compile failed, /tmp/BUILD/gdb-17.1-build/gdb-17.1/gdb/testsuite/gdb.base/infcall-nested-structs.c: In function 'void breakpt()':
/tmp/BUILD/gdb-17.1-build/gdb-17.1/gdb/testsuite/gdb.base/infcall-nested-structs.c:414:3: warning: '++' expression of 'volatile'-qualified type is deprecated [-Wvolatile]
414 | v++;
| ^
UNRESOLVED: gdb.base/infcall-nested-structs-c++.exp: types-tl: failed to compile
My understanding is that, in C++20, some operations on volatile
variables are now deprecated. So things like:
volatile int var = 0;
++var;
--var
var += 1;
var -= 1;
Are now, I believe, all deprecated. However, this is still allowed:
var = var + 1;
There are a few test cases where this impacts us, though in every case
the increment of the volatile only existed in order to create filler
work, as far as I can tell the volatile variable is never inspected
from GDB.
In gdb.base/infcall-nested-structs.c I just deleted the volatile
completely.
In the other tests I replaced the '++' with 'var = var + 1' type code.
I don't believe there should be any change in what is actually being
tested after this patch.
Alan Modra [Thu, 19 Feb 2026 04:48:12 +0000 (15:18 +1030)]
gas: don't use frag_more to repeat copies
It's more elegant to use the repeat capability of an rs_fill frag_var,
and dramatically reduces memory usage for large repeat counts.
For ideal minimal memory use, repeats of up to the 100 bytes or so of
frag overhead should be handled by frag_more, but I don't care to
optimise those cases. It's enough that the most common case of a
single output value uses frag_more, while stress testing the assembler
with huge repeats doesn't run into OOM.
* read.c (float_cons): Repeat output using an rs_fill frag_var
rather than looping with frag_more.
(s_float_space): Likewise.
Tom Tromey [Mon, 23 Jan 2023 04:43:59 +0000 (21:43 -0700)]
Save breakpoints so they are automatically pending
PR breakpoints/18183 points out that breakpoints saved with the "save
breakpoints" command can be slightly inconvenient, depending on "set
breakpoint pending".
This patch makes use of the new "with" command to save breakpoints
such that they will automatically be made pending, if necessary, when
being restored.
Unfortunately, reloading a breakpoint saved this way will also print:
No symbol table is loaded. Use the "file" command.
This seems strange to me, and also a bit useless, but changing
create_breakpoint not to call exception_print in the AUTO_BOOLEAN_TRUE
case caused other regressions, so I've left it as-is for the time
being.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18183 Reviewed-By: Keith Seitz <keiths@redhat.com>
AMDGCN: Disable subdirectory configuration for unsupported GAS and LD
The `amdgcn' target is not supported by GAS or LD, so disable building
in the respective subdirectories, removing configuration errors such as:
This target is no longer supported in gas
make[1]: *** [Makefile:5473: configure-gas] Error 1
and:
*** ld does not support target amdgcn-unknown-none
*** see ld/configure.tgt for supported targets
make[1]: *** [Makefile:6968: configure-ld] Error 1
in builds where no explicit `--disable-gas' and `--disable-ld' options
have been used with the top-level `configure' script. Users must not
have to disable features selected by default to get a working
configuration.
MIPS/BFD: Avoid section ordering breaking DYNAMIC segment for IRIX 5
With MIPS targets using the IRIX 5 linker emulation the DYNAMIC segment,
unusually, gets all of: `.dynamic', `.hash', `.dynsym', and `.dynstr'
sections mapped to, as well as any other sections placed in between.
No attention is paid as to which of these sections comes first though,
which would make such a DYNAMIC segment unusable at load time unless it
starts with the `.dynamic' section, if not for LD terminating the link
with:
The first section in the PT_DYNAMIC segment is not the .dynamic section
error message.
Our standard linker scripts ensure the correct section ordering, however
a user-supplied script may not, and it seems suboptimal to prevent users
from reordering sections to their liking.
Modify MIPS IRIX 5 linker emulation handling then so that only `.hash',
`.dynsym', and `.dynstr' sections that come after `.dynamic' in output,
and any other sections placed in between, get mapped to the DYNAMIC
segment.
This preserves exact IRIX 5 semantics for all the conforming scripts,
while letting people use a different order rather than getting a link
error. The error result previously issued means there is no backwards
compatibility to consider as no output used to be produced.
This removes a number of test failures:
-FAIL: PROVIDE_HIDDEN test (auxiliary shared object)
-FAIL: PROVIDE_HIDDEN test 4
-FAIL: PROVIDE_HIDDEN test 6
-FAIL: PROVIDE_HIDDEN test 10
-FAIL: PROVIDE_HIDDEN test 12
-FAIL: readelf version information
-FAIL: PR ld/20828 forcibly exported symbol version without section GC
-FAIL: PR ld/21233 dynamic symbols with section GC (auxiliary shared library)
across MIPS targets using the IRIX 5 linker emulation, such as
`mips-sgi-irix5', `mips-elf', `mips-rtems', etc.
ELF/BFD: Factor in inter-section padding for DYNAMIC segment
The vast majority of ELF targets only maps the `.dynamic' section in the
DYNAMIC segment, however MIPS targets using the IRIX 5 linker emulation
place all of: `.dynamic', `.hash', `.dynsym', and `.dynstr' sections
there, as well as any other sections placed in between. While the four
named sections have a fixed 4-byte alignment, other sections may require
a larger alignment causing extra padding to be produced as the sections
are laid out in linker output and mapped to segments. It is taken into
account in calculating the size for segments of the LOAD and TLS types,
but not for the DYNAMIC one.
Consequently the segment may get truncated, as illustrated with the
`dynamic-sections-2' test case included, which causes the following
mapping to be produced with the `mips-sgi-irix5' target, as well as
numerous bare metal ones such as `mips-elf' or `mips-rtems':
There are 12 section headers, starting at offset 0x139c:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .MIPS.abiflags MIPS_ABIFLAGS 00000000 001000 000018 18 A 0 0 8
[ 2] .dynamic DYNAMIC 00000018 001018 0000c8 00 A 6 0 4
[ 3] .hash HASH 000000e0 0010e0 00002c 00 A 5 0 4
[ 4] .data PROGBITS 00000110 001110 000010 00 WA 0 0 16
[ 5] .dynsym DYNSYM 00000120 001120 000060 10 A 6 2 4
[ 6] .dynstr STRTAB 00000180 001180 000049 00 A 0 0 4
[ 7] .rel.dyn REL 000001cc 0011cc 000010 08 A 5 0 4
[ 8] .got PROGBITS 000001e0 0011e0 00000c 04 WAp 0 0 16
[ 9] .symtab SYMTAB 00000000 0011ec 0000f0 10 10 9 4
[10] .strtab STRTAB 00000000 0012dc 000063 00 0 0 1
[11] .shstrtab STRTAB 00000000 00133f 00005d 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), p (processor specific)
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 3 program headers, starting at offset 52
-- notice `.dynstr' missing from the section to segment mapping shown
above, owing to the trailing part of the section extending beyond the
end of the segment, and the memory size of the DYNAMIC segment smaller
than its file size.
Apply the same memory size adjustment for padding to segments of the
DYNAMIC type as already made for segments of the LOAD and TLS types,
observing that semantically DYNAMIC segments are analogous except for
only having the lone `.dynamic' section mapped with the vast majority
of ELF targets.
Tom de Vries [Tue, 17 Feb 2026 18:20:50 +0000 (19:20 +0100)]
[gdb/testsuite] Fix some incorrect uses of decimal
Dejagnu defines $decimal as:
...
set decimal "\[0-9\]+"
...
If we add an equivalent definition in lib/gdb.exp:
...
set decimal "(?:\[0-9\]+)"
...
we run into this type of ERRORs:
...
couldn't compile regular expression pattern: parentheses () not balanced
...
This is due to using "\[$decimal\]" instead of "\\\[$decimal\\]" or
"[subst_var {\[$decimal\]}]".
Add such definitions of decimal and hex, and apply the same technique to
positive and octal.
Kevin Buettner [Thu, 29 Jan 2026 22:09:24 +0000 (15:09 -0700)]
gcore: Handle unreadable pages within readable memory regions
GLIBC 2.42 changed how thread stack guard pages are implemented [2].
In GLIBC 2.41 and earlier, guard pages were set up using mprotect() to
mark guard regions with no permissions. Once configured, guard pages
were visible as separate entries in /proc/PID/maps with no permissions
(i.e. they're inaccessible). In GLIBC 2.42, guard pages are
installed using the kernel's MADV_GUARD_INSTALL mechanism [1], which
marks them at the page table entry (PTE) level within the existing
mapping.
As a consequence, guard pages do not appear as separate entries in
/proc/PID/maps, but remain as part of the containing mapping. Moreover,
thread stacks from multiple mmap() calls may be merged into a single
virtual memory area (VMA) with read and write permissions since there's
no guard page VMA to separate them. These guard pages cannot be
distinguished by examining VMA listings but do return EIO when read
from /proc/PID/mem.
GDB's gcore code reads /proc/PID/smaps to discover memory regions and
creates one BFD section per mapping. (On linux, this is performed in
linux_find_memory_regions_full in linux-tdep.c.) With the old layout,
memory areas with guard pages appeared separately with no permissions,
which were filtered out. Each thread stack became its own section
containing only readable data. With the new layout, using
MADV_GUARD_INSTALL instead of the older mechanism, it's often the case
that thread stacks created with multiple calls to mmap() are exposed
as a single mapping appearing in /proc/PID/smaps with read and write
permissions. Should that happen, GDB's code creates a single section
covering all thread stacks and their guard pages. (Even if each
thread stack appears in its own mapping, the fact remains that there
will be an inaccessible portion of the mapping. When one or more
thread stacks are coalesced into a single mapping, there will be
several inaccessible "holes" representing the guard pages.)
When gcore_copy_callback copies section contents, it reads memory in
1MB (MAX_COPY_BYTES) chunks. If any page in the chunk is a guard page,
the call to target_read_memory() fails. The old code responded by
breaking out of the copy loop, abandoning the entire section. This
prevents correct copying of thread stack data, resulting in core files
with zero-filled thread stacks, resulting in nearly empty backtraces.
Fix this by falling back to page-by-page reading when a 1MB chunk read
fails. Individual pages that cannot be read are filled with zeros,
allowing the remaining readable memory to be captured.
I also considered a simpler change using the value of
FALLBACK_PAGE_SIZE (4096) as the read size instead of MAX_COPY_BYTES
(1MB). This would avoid the fallback logic but would cause up to 256x
more syscalls. The proposed approach also allows meaningful warnings:
we warn only if an entire region is unreadable (indicating a real
problem), whereas per-page reads would make it harder to distinguish
guard page failures from actual errors. Since guard pages are at
offset 0 for downward-growing stacks, a large target_read_memory()
fails early at the first unreadable byte anyway.
With this fix, I see 16 failures resolved in the following test cases:
Looking at just one of these, from gdb.log without the fix, I see:
thread apply 5 backtrace
Thread 5 (LWP 3414829):
#0 0x00007ffff7d1d982 in __syscall_cancel_arch () from /lib64/libc.so.6
#1 0x0000000000000000 in ?? ()
(gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: thread apply 5 backtrace
And this is what it looks like with the fix in place (some paths have
been shortened):
thread apply 5 backtrace
Thread 5 (Thread 0x7fffeffff6c0 (LWP 1282651) "threadcrash"):
#0 0x00007ffff7d1d982 in __syscall_cancel_arch () from /lib64/libc.so.6
#1 0x00007ffff7d11c3c in __internal_syscall_cancel () from /lib64/libc.so.6
#2 0x00007ffff7d61b62 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6
#3 0x00007ffff7d6db37 in nanosleep () from /lib64/libc.so.6
#4 0x00007ffff7d8008e in sleep () from /lib64/libc.so.6
#5 0x00000000004006a8 in do_syscall_task (location=NORMAL) at threadcrash.c:158
#6 0x0000000000400885 in thread_function (arg=0x404340) at threadcrash.c:277
#7 0x00007ffff7d15464 in start_thread () from /lib64/libc.so.6
#8 0x00007ffff7d985ac in __clone3 () from /lib64/libc.so.6
(gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior: thread apply 5 backtrace
Regression testing on Fedora 42 (glibc 2.41) shows no new failures.
The v1 patch used SPARSE_BLOCK_SIZE as the fallback size. While it
was the correct size, it's used for an entirely different purpose
elsewhere in this file. This v2 commit introduces the constant
FALLBACK_PAGE_SIZE instead.
Tom de Vries [Tue, 17 Feb 2026 14:45:23 +0000 (15:45 +0100)]
[gdb/doc] Improve info line command documentation
The "info line" command can be used with or without arguments.
About using it without arguments, the documentation [1] says the following:
...
info line
With no locspec, information about the current source line is printed.
...
After info line, using info line again without specifying a location will
display information about the next source line.
...
That does not describe the fact that the command may also show the last line
listed:
...
(gdb) info line
No line number information available.
(gdb) list main
20 #include "interps.h"
21 #include "run-on-main-thread.h"
22
23 int
24 main (int argc, char **argv)
25 {
26 /* The first call to is_main_thread () should be from the main thread.
27 If this is the first call, then that requirement is fulfilled here.
28 If this is not the first call, then this verifies that the first call
29 fulfilled that requirement. */
(gdb) info line
Line 29 of "gdb/gdb.c" is at address 0x419684 <main(int, char**)+30>
but contains no code.
(gdb)
...
Update the documentation to list this additional functionality.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33783
Tom de Vries [Tue, 17 Feb 2026 14:31:32 +0000 (15:31 +0100)]
[gdb/build] Require makeinfo 5.0
Building GDB documentation in the info format requires makeinfo 5.0 [1].
Bail out when trying to use an older makeinfo version.
I tested this by requiring 7.0 in two setups that have respectively makeinfo
7.1 and 6.5.
In the 7.1 case I got (make output):
...
makeinfo-wrapper.sh 7 0 makeinfo ... -o gdb.info gdb/doc/gdb.texinfo
makeinfo-wrapper.sh 7 0 makeinfo ... -o annotate.info gdb/doc/annotate.texinfo
rluser.texi:2: warning: @setfilename after the first element
...
and in the 6.5 case I got instead:
...
makeinfo-wrapper.sh 7 0 makeinfo ... -o gdb.info gdb/doc/gdb.texinfo
makeinfo-wrapper.sh 7 0 makeinfo ... -o annotate.info gdb/doc/annotate.texinfo
makeinfo is too old, have 6.5, require 7.0. Info documentation will not be build.
makeinfo is too old, have 6.5, require 7.0. Info documentation will not be build.
...
Checked new file gdb/doc/makeinfo-wrapper.sh with shellcheck.
Changes in v2:
- handle version line 'texi2any (GNU texinfo) 7.2.90+nc'
Changes in v3:
- handle version line 'texi2any (GNU texinfo) 5.0+dev'
LD/testsuite: Enable execution with remote targets
Lift target execution limitation from `run_ld_link_exec_tests' procedure
and also handle remote targets, albeit in a restricted way, as follows.
Numerous test cases have been written such that they refer to a shared
library using a relative path, precluding the use of the runtime library
search path for the dependency to be found at run time. Consequently a
test affected has to be run on the target such that the shared library
required is present at the same relative path rooted at the program's
current working directory.
Additionally any shared library dependencies are not handled across the
test suite in an organised way, so test invocations only have names of
direct dependencies buried within the linker options supplied.
Therefore assert that the linker test directory is located at the same
absolute path both on the test host and the test target, typically via
sharing the directory over NFS, and use the DejaGNU `remotedir' feature
to start execution on the target with that location as the test case's
current working directory.
Complementing `check_compiler_available' procedure for a compilation
check implement `check_execution_available' that checks whether an
executable built the same way can actually successfully run on the
target.
LD/testsuite: Factor out compilation of a dummy executable
There is a dummy executable compiled for the purpose of determining
whether a target compiler is available that can produce a runnable
program. This is now going to be also used to determine whether a
program produced this way can be executed on the target, so take the
relevant pieces from `check_compiler_available' procedure and factor
them out to `make_dummy_target_executable' procedure leaving the
executable produced in place and returning its name upon successful
compilation. This executable needs to be discarded by the caller once
no longer needed. No functional change overall.
Alan Modra [Mon, 16 Feb 2026 23:29:37 +0000 (09:59 +1030)]
gas: abort in new_logical_line_flags
.linefile 0.
hits the "case 1 << 3" abort in new_logical_line_flags with line_number
of -1.
Similar to commit b60f6a628897, this fixes the abort by extending the
meaning of .linefile in user code to restore the physical line for
".linefile 0 .".
* input-scrub.c (new_logical_line_flags <case 1<<3>): Don't
abort on negative line number, instead restore physical line
for ".linefile 0".
Alan Modra [Mon, 16 Feb 2026 23:29:13 +0000 (09:59 +1030)]
gas: macros nested too deep error
.macro r;r;.endm;r
Currently reports:
nest.s: Assembler messages:
nest.s:2: Fatal error: macros nested too deeply
nest.s:2: Info: macro invoked from here
nest.s:2: Info: macro invoked from here
...
nest.s:2:<much indenting> Info: macro invoked from here
nest.s:1:<much indenting> Info: macro invoked from here
This patch corrects the line number reported, and downgrades the error
from as_fatal to as_bad.
* input-scrub.c (input_scrub_include_sb): Report "macros
nested too deeply" using as_bad.
* macro.c (buffer_and_nest): Only bump line number in .lineinfo
if we have a '\n'.
Alan Modra [Mon, 16 Feb 2026 23:27:52 +0000 (09:57 +1030)]
gas: further limit .rept count
gas currently limits a rept count at 0x7fffffff. With a minimal rept
body this requires at least 2G * 16 due to the .linefile directive
added by buffer_and_nest. I'm inclined to think 32G is excessive.
This patch limits the total memory used by rept to 4G (2G on 32-bit
systems). That of course reduces allowed repeat counts by a factor of
at least 8, and note that the file name affects the max repeat.
The patch also changes the repeat count to 1 rather than 0 when
we hit the limit, so that the body of the rept is not entirely ignored.
Nested rept can still easily cause OOM of course.
* read.c (do_repeat): Limit allowed repeat count based on
total memory needed.
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.
projects / thirdparty / binutils-gdb.git / log
