Andrew Burgess [Tue, 10 Feb 2026 15:14:09 +0000 (15:14 +0000)]
gdb: aliases for some skip related commands
Skips are created using 'skip', 'skip file', or 'skip function', then
managed with 'skip enable', 'skip disable', and 'skip delete'.
This is slightly different to other things, for example breakpoint,
where we have a command to create the thing, e.g. 'break', but then we
have 'enable breakpoints', 'disable breakpoints', and 'delete
breakpoints' to manage the thing.
If you tab-complete on any of the 'enable', 'disable', or 'delete'
prefix commands you'll find these are used to manage a whole bunch of
different types of thing.
When I started playing with skips, my instinct, given the existing
patterns in GDB, was to try 'enable skip', 'disable skip', and 'delete
skip', and it surprised me that these didn't work.
But notice we do have 'info skip' rather than 'skip info'. So the
"normal" pattern does apply in some cases.
In this commit I propose that we create aliases 'enable skip',
'disable skip', and 'delete skip' which just alias back to the
existing commands. We cannot delete the existing commands for fear of
breaking existing user scripts.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Add a new "environ" subcommand to "info proc" to print the initial
environment variables of a given process. The environment variables
are printed line-by-line and are indented by two spaces, so that they
can be distinguished from the rest of the output in "info proc all".
Note that the information printed by this new command is not
necessarily the same as `show environment`, which lists the
environment variables that will be given to the program next time it
is started under GDB. The two information may differ in particular
when GDB attached to a running program that was started in an
environment different than GDB's.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
gdb: remove 'num' field from 'struct address_space'
The getter method `num ()` in `struct address_space` is never used.
Remove it. This leads to two more simplifications: (1) the
address_space constructor can be defaulted in the header, (2)
`highest_address_space_num` global counter is no longer needed and can
be removed.
Tested by re-building.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Tue, 24 Feb 2026 21:22:15 +0000 (07:52 +1030)]
Re: gas: macros nested too deep error
In commit fc2fcd4f5be3 I changed as as_fatal to as_bad, thinking that
was sufficient. Revert that change because
.macro r;r;r;.endm;r
with two recursive invocations in the body results in 2 to the power
max_macro_nest lines of gas output complaining about macro nesting.
* input-scrub.c (input_scrub_include_sb): Revert last change.
Tom Tromey [Mon, 9 Feb 2026 14:13:33 +0000 (07:13 -0700)]
Sort and uniquify Ada standard exceptions
With libgnat debuginfo installed, I noticed some test failures.
This patch fixes gdb.ada/info_exc.exp and gdb.ada/mi_exc_info.exp,
both of which had failures caused by not unique-ifying the list of
standard exceptions.
Tom Tromey [Sun, 8 Feb 2026 21:39:50 +0000 (14:39 -0700)]
Fix Ada failure with gdb-index
The gdb index reader rewrite (commit 486bc5ac) broke a couple of Ada
test cases. I didn't notice these at the time because they require
libgnat debuginfo to be installed.
This patch fixes the problem. The issue here is that the Ada code
sometimes requires types to have "linkage name" entries. This is
required because these lookups are done using the verbatim ("<...>")
notation, which won't match the split names in the index.
Removing the need for this is on my wish-list, see PR ada/32142; but I
have not gotten around to figuring this one out yet.
In the meantime, having the gdb-index reader create synthetic linkage
name entries for types fixes the bug.
Jan Vrany [Tue, 24 Feb 2026 15:24:31 +0000 (15:24 +0000)]
gdb/testsuite: fix test build-id-no-debug-warning.exp with -readnow
Test build-id-no-debug-warning.exp fails when using -readnow. This is
because in that case GDB outputs "Expanding full symbols from..." after
"Reading symbols from ...".
Jan Vrany [Tue, 24 Feb 2026 15:24:31 +0000 (15:24 +0000)]
gdb/testsuite: fix test crc_mismatch.exp with -readnow
Test crc_mismatch.exp fails when using -readnow. This is because in that
case GDB outputs "Expanding full symbols..." after "Reading symbols from
...".
Tom de Vries [Tue, 24 Feb 2026 13:35:40 +0000 (14:35 +0100)]
[gdb/record] Fix return value for svc in aarch64_record_branch_except_sys
The Linaro CI reported the following regression in test-case
gdb.reverse/sigall-reverse.exp on aarch64-linux:
...
(gdb) continue^M
Continuing.^M
The next instruction is syscall exit_group. It will make the program exit. \
Do you want to stop the program?([y] or n) yes^M
Process record does not support instruction 0xd4000001 at address $hex.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
__GI__exit (status=status@entry=0) at ../sysdeps/unix/sysv/linux/_exit.c:30^M
30 INLINE_SYSCALL (exit_group, 1, status);^M
(gdb) FAIL: gdb.reverse/sigall-reverse.exp: continue to signal exit
...
due to commit 0cb5fde010a ("[gdb/testsuite] Fix some incorrect uses of
decimal").
[ Note that 0xd4000001 is "svc #0", the syscall instruction. ]
The test fails because it expects "Process record: inferior program stopped":
...
gdb_test "continue" "Process record: inferior program stopped.*" \
"continue to signal exit" \
"The next instruction is syscall exit_group.* program...y. or n. " \
"yes"
...
instead of "Process record: failed to record execution log".
The problem is caused by the fact that there are two result value domains:
- one for generic record (res < 0, res == 0, and res > 0) and
- one for aarch64 record (AARCH64_RECORD_SUCCESS = 0, AARCH64_RECORD_UNSUPPORTED = 1
and AARCH64_RECORD_UNKNOWN = 2, and an unnamed -1).
When returning here from aarch64_record_branch_except_sys:
...
return tdep->aarch64_syscall_record (aarch64_insn_r->regcache,
svc_number);
...
we transfer from the generic record domain to the aarch64 record domain, converting:
- a value 1, meaning "Process record: inferior program stopped", into
- a value AARCH64_RECORD_UNSUPPORTED, meaning
"Process record does not support instruction $hex at address $hex.
Process record: failed to record execution log.".
[ Then again, the transfer of domains might be in aarch64_linux_syscall_record.
It's kind of hard to say, given that typing is not used to distinguish between
the two domains. ]
Fix this by:
- introducing a conversion function to_aarch64_record_result, and
- using it in aarch64_record_branch_except_sys.
Likewise, add a from_aarch64_record_result and use it in
aarch64_process_record.
Also add some documentation to enum aarch64_record_result, and add the missing
-1 value.
AFAICT, the loongarch port needs the same fix, but I can't test that so I
think it's better to only deal with aarch64 in this patch.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33913
Alan Modra [Tue, 24 Feb 2026 11:18:14 +0000 (21:48 +1030)]
readelf: endless loop on attrv2
Given a short attributes section, elf_parse_attrs_subsection_v2 prints
an error message but does not return an error status or consume any
input. That results in endless printing of "Object attributes section
ends prematurely". The length checks also ignored a single excess
byte at the end of the section.
* readelf.c (elf_parse_attrs_subsection_v2): Move various
constants out of function. Don't check for min length here..
(process_attributes_v2): ..do so here instead.
Alan Modra [Sun, 22 Feb 2026 04:52:43 +0000 (15:22 +1030)]
readelf .debug_aranges header display
Print "Address size" rather than "Pointer Size" and "Segment size"
rather than "Segment Size", using the same names and capitalisation
as is used when printing other headers with these fields.
Alan Modra [Mon, 23 Feb 2026 00:57:15 +0000 (11:27 +1030)]
binutils: rename ar_pointer_size
The field is named "address size" in all versions of the DWARF spec
that have and name the field. Reflect that by renaming
ar_pointer_size to ar_address_size.
Alan Modra [Mon, 23 Feb 2026 00:48:17 +0000 (11:18 +1030)]
PR 33914 abort parsing fuzzed .debug_line
The abort is due to an unexpected DW_FORM_addrx3 entry in the
testcase, which requires pointer_size to be known.
* dwarf.c (address_size_ok): New function.
(read_debug_line_header): Use address_size_ok.
(display_formatted_table): Pass li_address_size as
pointer_size to read_and_display_attr_value.
(display_debug_lines_decoded): Likewise.
(display_debug_macro, display_debug_names): Similarly pass
offset_size.
(display_loclists_unit_header): Use address_size_ok.
(display_debug_loc, display_debug_addr): Likewise.
(display_debug_aranges): Likewise. Remove power of two check
on address_size. Calculate and pad to tuple_size.
Since commit 120072c7cdc ("gdb/testsuite: update C++ tests for volatile
changes in C++20") I see regressions in two test-cases:
...
$ ./sum.sh
4300 gdb.base/infcall-nested-structs-c++.exp:
2500 gdb.base/infcall-nested-structs-c.exp:
...
In more detail, in test-case gdb.base/infcall-nested-structs-c++.exp:
...
(gdb) tbreak 421^M
No compiled code for line 421 in the current file.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: $exp: types-tc: gdb_breakpoint: set breakpoint at 421
...
Fix this by reverting the change done by the commit, and applying the same fix
as the commit applied elsewhere:
...
- v++;
+ v = v + 1;
...
Tested on x86_64-linux, with target boards unix and unix/-std=c++20.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33915
Kevin Buettner [Wed, 18 Feb 2026 01:09:08 +0000 (18:09 -0700)]
gcore: Query auxv for AT_PAGESZ in gcore_copy_callback
This is a followup patch to commit c1da013915e, titled "gcore: Handle
unreadable pages within readable memory regions".
In his review of that earlier patch, Tom de Vries recommended using
target_auxv_search with AT_PAGESZ to find the page size if it's
available; this patch implements that suggestion. As before, a 4k
fallback size is used should the search for an AT_PAGESZ value not
succeed.
Alan Modra [Sat, 21 Feb 2026 00:26:57 +0000 (10:56 +1030)]
PR 33917 Internal error in S_SET_SEGMENT
Commit d4d05d13eba6 attempted to fix a similar error to that uncovered
by the testcase in pr33917, but did so in a way that was wrong.
Modifying an undefined_section symbol that is an equate breaks prior
use of that symbol, as shown in the rewrite of the
section-symbol-redef test.
Another oddity found when poking at pr33917 is that gas allows
x=0
.sect x
x=u
while
.sect x
x=u
fails with "Error: symbol `x' is already defined".
Fix all of this by rewriting section_symbol to properly check for the
only case where we want to redefine an existing symbol, a truly
undefined symbol, and always use section_symbol in obj-elf rather than
trying to handle undefined symbols there too.
PR 33917
* config/obj-elf.c (change_section): Always call section_symbol
to set up sym.
* subsegs.c (section_symbol): Rewrite.
* testsuite/gas/elf/section-symbol-redef.d
* testsuite/gas/elf/section-symbol-redef.s: Rewrite.
* testsuite/gas/elf/section-symbol-redef-2.d,
* testsuite/gas/elf/section-symbol-redef-2.s: New test.
* testsuite/gas/elf/elf.exp: Run new test.
Alan Modra [Sat, 21 Feb 2026 00:26:49 +0000 (10:56 +1030)]
Make Solaris global ABI syms STT_OBJECT and STV_PROTECTED
PR 33177
* emultempl/solaris2.em (elf_solaris_before_allocation): Make
globals defined here STV_PROTECTED and STT_OBJECT. Use
elf_backend_hide_symbol rather that just setting forced_local
for local ABI syms.
Alan Modra [Sat, 21 Feb 2026 00:26:43 +0000 (10:56 +1030)]
PR 12320 ld --as-needed links libgcc_s.so.1 unnecessarily on Solaris
The Solaris 2 ABI requires some global symbols to be present as
dynamic symbols. These unfortunately interact with ld --as-needed.
See the comment above elf-solaris.c:elf_solaris2_add_symbol_hook,
a new function added by this patch to ignore those symbol in shared
libraries.
PR 12320
PR 33177
bfd/
* elf-solaris2.c: New file.
* elf-solaris2.h: New file.
* elf32-i386.c (elf_backend_add_symbol_hook): Define for Solaris.
* elf32-sparc.c (elf_backend_add_symbol_hook): Likewise.
* elf64-sparc.c (elf64_sparc_solaris2_add_symbol_hook): New.
(elf_backend_add_symbol_hook): Define for Solaris.
* elf64-x86-64.c (elf_x86_64_solaris2_add_symbol_hook): New.
(elf_backend_add_symbol_hook): Define for Solaris.
* Makefile.am (BFD32_BACKENDS): Add elf-solaris2.lo.
(BFD32_BACKENDS_CFILES): Add elf-solaris2.c.
* configure.ac (elfxx_x86): Add elf-solaris2.lo.
(elfxx_sparc): Define and use in all sparc_elf*_vec.
* po/SRC-POTFILES.in: Regenerate.
* Makefile.in: Regenerate.
* configure: Regenerate.
ld/
* emultempl/solaris2.em (elf_solaris2_after_open): New function.
(LDEMUL_AFTER_OPEN): Define.
(elf_solaris_before_allocation): Delete global_syms, instead
use elf_solaris2_global_syms. Ignore globals that are still
bfd_link_hash_new, ie. have not been defined by a script.
Alan Modra [Sat, 21 Feb 2026 00:26:33 +0000 (10:56 +1030)]
Solaris emulation check
elf_solaris2_before_allocation can be called when ld output is non-ELF,
but also when ld output is ELF but not Solaris. Split out from the
pr12320 fix due to the indentation change.
PR 12320
PR 33177
* emultempl/solaris2.em (elf_solaris_before_allocation): Wrap
everything done here in a more rigorous output hash table check.
I tracked this down to a race condition in the test program, causing it
not to generate the expected SIGTRAP. This can be reproduced by adding
a sleep(1) just after the pthread_create.
The expected behavior is:
- The main thread starts a second thread
- The main thread blocks on pthread_cond_wait, waiting to be notified
by the second thread (to make sure the second thread had time to
start)
- The second thread notifies the main thread using pthread_cond_signal
- The main thread sends a SIGTRAP to the second thread
However, this can happen:
- The main thread starts a second thread
- The second thread calls pthread_cond_signal, while no one is waiting
to the condvar
- The main thread blocks on pthread_cond_wait forever
Fix it by introducing a separate boolean predicate protected by the
shared mutex, and looping until it is true. This is the way
pthread_cond_wait is meant to be used. From pthread_cond_wait(3):
When using condition variables there is always a boolean predicate
involving shared variables associated with each condition wait that
is true if the thread should proceed. Spurious wakeups from the
pthread_cond_wait() or pthread_cond_timedwait() functions may occur.
Since the return from pthread_cond_wait() or
pthread_cond_timedwait() does not imply anything about the value of
this predicate, the predicate should be re-evaluated upon such
return.
Finally, make things static, just out of principle, and fix minor
formatting issues.
Change-Id: I62ba2085a2d506dc3d91e32cd5de48c43a3ff55e Approved-By: Tom Tromey <tom@tromey.com>
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.
projects / thirdparty / binutils-gdb.git / log
