H.J. Lu [Fri, 26 Sep 2025 00:03:01 +0000 (08:03 +0800)]
binutils: Pass target plugin file to target ar/nm/ranlib
There are 2 kinds of binutils tests:
1. Tests of binutils object files and libraries using the build tools,
like CC, AR, NM and RANLIB.
2. Tests of binutils programs as the target tools, like CC_FOR_TARGET,
AR_FOR_TARGET, NM_FOR_TARGET and RANLIB_FOR_TARGET.
Set AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and
RANLIB_PLUGIN_OPTION_FOR_TARGET to the target compiler plugin file for
target ar/nm/ranlib.
PR binutils/33483
* Makefile.in: Regenerated.
* configure: Likewise.
* Makefile.tpl (AR_FOR_TARGET): Add @AR_PLUGIN_OPTION_FOR_TARGET@.
(NM_FOR_TARGET): Add @NM_PLUGIN_OPTION_FOR_TARGET@.
(RANLIB_FOR_TARGET): Add @RANLIB_PLUGIN_OPTION_FOR_TARGET@.
* configure.ac: Use CLANG_PLUGIN_FILE_FOR_TARGET and
GCC_PLUGIN_OPTION_FOR_TARGET to set AR_PLUGIN_OPTION_FOR_TARGET,
NM_PLUGIN_OPTION_FOR_TARGET and RANLIB_PLUGIN_OPTION_FOR_TARGET.
AC_SUBST AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET
and RANLIB_PLUGIN_OPTION_FOR_TARGET.
Tom de Vries [Fri, 26 Sep 2025 23:54:18 +0000 (01:54 +0200)]
[gdb/testsuite] Drop tclsh dependency
The test-case gdb.tui/tuiterm-2.exp uses a tcl script gdb.tcl that uses tclsh
as its interpreter:
...
#!/usr/bin/env tclsh
...
I used tclsh because I assumed it was an existing dependency of
dejagnu/expect, but apparently [1] that's not the case.
IWBN to use some existing dependency instead.
Using expect instead of tclsh also works on my system, but looking in
/usr/bin/runtest I realized that someone might have a dejagnu setup with
a custom expect indicated by setting an env var EXPECT. So to find expect
we'd have to mimic whatever runtest is doing to find expect, or do:
...
$ runtest --version -v | grep "Expect binary"
...
using the appropriate runtest.
That sounds non-trivial and fragile, so simply use a shell script with /bin/sh
interpreter instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-September/220736.html
Tom de Vries [Fri, 26 Sep 2025 23:20:56 +0000 (01:20 +0200)]
[gdb/testsuite] Handle wrap mode unsupported in gdb.tui/wrap-line.exp
When running test-case gdb.tui/wrap-line.exp on msys2-ucrt64, we run into some
fails in the CLI part of the test-case because:
...
(gdb) maint info screen
...
Readline wrapping mode: unsupported (terminal is not Cursor Up capable)
...
Fix this by requiring wrapping mode "readline" for that part of the test-case.
Tom de Vries [Fri, 26 Sep 2025 23:20:56 +0000 (01:20 +0200)]
[gdb/testsuite] Fix timeout in gdb.tui/wrap-line.exp
When running test-case gdb.tui/wrap-line.exp on msys2-ucrt64, I run into a
timeout here:
...
set test "startup prompt"
gdb_test_multiple "" $test {
-re "^$gdb_prompt $" {
pass "$test"
}
}
...
due to running into "^[[6n(gdb) ".
Fix this by allowing this, similar to how this was fixed in default_gdb_start by
commit 7e1964f9c61 ("[gdb/testsuite] Set TERM to dumb by default").
Tom de Vries [Fri, 26 Sep 2025 23:13:16 +0000 (01:13 +0200)]
[gdb/testsuite] Improve gdb.tui/pr30056.exp
Fix a few things I noticed while working on test-case gdb.tui/pr30056.exp:
- unnecessary indentation due to save_vars
- missing gdb_assert checking the result of Term::wait_for_region_contents
- redundant comment "Uncomment this to simulate that PR cli/30498 is fixed"
Tom de Vries [Fri, 26 Sep 2025 23:13:16 +0000 (01:13 +0200)]
[gdb/testsuite] Remove wait in gdb.tui/pr30056.exp
In test-case gdb.tui/pr30056.exp, we have:
...
# Send arrow-right.
send_gdb "\033\[C"
# We need the arrow-right to be processed by readline, before we
# send the following ^C. Waiting 1 ms seems to do that.
after 1
...
Waiting for an effect by sleeping is fragile.
The reason we're doing so is that we're waiting for an effect that is not
visible: the arrow-right is meant to horizontally scroll the source window,
but since there's no source, nothing happens.
Fix this by using an executable in the test-case, with a source file
containing a comment long enough to make horizontal scrolling possible.
Fixing this means we no longer run into PR33371, so that PR will need its own
test-case.
Tom Tromey [Wed, 3 Sep 2025 15:26:25 +0000 (09:26 -0600)]
Always propagate exceptions in DAP
This changes the DAP exec_and_log function to always transform an
exception into a DAPException and propagate it.
As the bug points out, we haven't always wrapped calls when
appropriate. I think it's better to cause the request to fail by
default; if any spot truly needs to ignore errors, that is readily
done at the point of call.
Tom Tromey [Wed, 3 Sep 2025 15:08:01 +0000 (09:08 -0600)]
Remove Invoker class from DAP
The Invoker used to be more convenient, before DAP requests were run
on the gdb thread by default. Now it is barely used and easily
replaced by a couple of lambdas.
Tom Tromey [Wed, 3 Sep 2025 17:54:57 +0000 (11:54 -0600)]
Fix minor bug in dap-support.exp
Commit faee137249c8 refactored dap-support.exp, but accidentally left
a reference to a variable that was renamed. I noticed this when an
earlier version of this series provoked one of the errors in this
code.
The second line of this code is probably a bug because it does nothing. It
was probably supposed to update "file->all_comp_units_without_ranges" to point
to "each" - the new head of the list.
Jan Beulich [Fri, 26 Sep 2025 10:21:11 +0000 (12:21 +0200)]
Dwarf: adjust fetch_indirect{,_line}_string()'s return type
As already is the case for fetch_indexed_string() and
fetch_alt_indirect_string(), have them return a pointer to plain char,
properly compatible with e.g. the %s format specifier that the return
values are used with in several cases. This way no casts at call sites are
necessary, and several (bogus) ones in the functions can be exchanged for
just one each. Some other constification is needed elsewhere, now that
const-ness isn't being cast away anymore.
PowerPC: Fix typo in PowerPC note pseudo-section names
The recent tidy-up commit 09e56f0515c3 ("Code tidy: bfd/elf.c:
Tidy up core note handling code.") introduced regressions in the
PowerPC core note handling. The pseudo-section names for TM_CVSX,
TM_SPR, VSX and VMX notes were defined with an underscore instead of a
hyphen, breaking GDB test cases. The same goes for one riscv and one
s390 define.
This patch restores the correct section names by using hyphens in the
definitions, fixing 897 GDB test failures on PowerPC.
bfd/
* elf.c: (NOTE_PSEUDO_SECTION_PPC_TM_CVSX),
(NOTE_PSEUDO_SECTION_PPC_TM_SPR, NOTE_PSEUDO_SECTION_PPC_VSX),
(NOTE_PSEUDO_SECTION_PPC_VMX, NOTE_PSEUDO_SECTION_RISCV_CSR),
(NOTE_PSEUDO_SECTION_S390_CTRS): Use hyphens in section names
instead of underscores.
Andrew Burgess [Thu, 25 Sep 2025 09:13:45 +0000 (10:13 +0100)]
gdb/doc: be more verbose about .gdb_index changes in version 9
I had reason to read the docs relating to .gdb_index format, and ended
up having to look at historical versions of the documentation in order
to clarify exactly what changed with the introduction of version 9.
Given that we claim versions 7, 8, and 9 are all still allowable index
versions, I think our docs should make it clear what the current
format is, but also what previous formats looked like.
I did try to do the same for the changes from 7 to 8, but even after
reading commit 796a7ff8234cfaa8a I'm still not entirely clear what
changed. If I gain some insight in the future then there might be a
follow on patch for that too.
Bruce McCulloch [Fri, 1 Nov 2024 16:31:46 +0000 (12:31 -0400)]
libctf: dump CTF array dimensions in the right order
Before GCC PR114186, all looked good in the land of
multidimensional arrays: you wrote
int a[5][10];
and ctf_type_aname() et al would print it as
int [5][10]
Unfortunately this was two bugs in one. GCC was emitting the array as if
it were int a[10][5], i.e. as this:
a -> [10] -> [5] -> int
rather than
a -> [5] -> [10] -> int
as it should be. libctf was hiding this by printing them in the wrong
order, concealing the bug from anyone using objdump --ctf or anything
but actual type graph traversal. Once this was fixed for GCC, the bug
was visible in libctf: multidimensional arrays were printed backwards!
(But this is just a print-time bug: the underlying bug, that something
traversing the type graph would see the array in backwards order, was
fixed by the fix to GCC.)
Fix this libctf bug, printing the arrays the right way round. In a
possibly futile attempt to retain some vestige of backwards
compatibility, introduce a new bug-compat flag CTF_F_ARRNELEMS, which,
if on, indicates that PR114186 is fixed and GCC is emitting array
elements the right way round. (Unfortunately, the fix went in without
this flag, so some GCCs will still emit CTF that will cause libctf to
print them wrong, even with this fix -- but it's no wronger than it was
before, and new GCC and new binutils, as well as GCC older than any fix
for PR114186 and new binutils, will print things properly. Someone
traversing the type graph will see things right after the GCC fix, wrong
before it, and there isn't really any reliable way to tell which you
have, though if CTF_F_ARRNELEMS is set, you definitely have a fixed GCC.
The test checks for this, but it's not something we expect actual users
to ever do -- CTF dict flags are an internal implementation detail with
no user-visible API for a reason.)
[nca: log message, test compat with older compilers]
include/
* ctf.h (CTF_F_ARRNELEMS): New bug-compat flag.
(CTF_F_MAX): Adjust.
libctf/
PR libctf/32161
* ctf-decl.c (ctf_decl_push): Prepend if this is an array and
the bug-compat flag is set.
* ctf-dump.c (ctf_dump_header): Dump the new bug-compat flag.
* testsuite/libctf-lookup/multidim-array*: New test.
Nick Alcock [Mon, 22 Sep 2025 20:07:11 +0000 (21:07 +0100)]
libctf: fix querying of large structures
After GCC PR 121411 is fixed, large structures (with offsets > 512MiB)
are written correctly... but libctf cannot query them properly unless
they are even bigger (> 4GiB), because it checks to see if the ctt_size
is CTF_LSIZE_SENT to decide whether to use a ctf_lmember_t or a
ctf_member_t to encode the structure members. But the structure member
offsets are in *bits*, not bytes: the right value to check is
CTF_LSTRUCT_THRESH, which is 1/8th the size.
(Thanks to Martin Pirker <martin.pirker1@chello.at> for the diagnosis
and fix.)
Testing this is a bit fun, because we don't want to emit an error if the
compiler is broken: but we cannot tell whether the compiler is broken
using the existing lookup harness, because its input is passed through
the linker (and thus the broken ld). So add another sort of link mode,
"objects", which keeps the constituent object files around and passes
both the final linker output and the object files that make it up to the
lookup program. Our testcase can then check the linker input to see if
the compiler is buggy, and only if it isn't check the linker output and
fail if things aren't right.
libctf/
PR libctf/33339
* ctf-types.c (ctf_struct_member): Check CTF_LSTRUCT_THRESH, not
CTF_LSIZE_SENT.
* testsuite/lib/ctf-lib.exp (run_lookup_test): New 'objects'
link option.
* testsuite/libctf-lookup/big-struct-corruption.*: New test.
* testsuite/libctf-lookup/big-struct-ctf.c: New test input.
H.J. Lu [Mon, 22 Sep 2025 20:24:00 +0000 (04:24 +0800)]
Binutils/GCC: Add clang LTO support to AR, NM and RANLIB
Add CLANG_PLUGIN_FILE to find the clang plugin file and pass it to
--plugin for ar, nm and ranlib so that binutils can be built with
clang LTO. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION since
GCC_PLUGIN_OPTION may return the wrong PLUGIN_OPTION with clang.
PR binutils/33470
* Makefile.in: Regenerated.
* Makefile.tpl (NM): Add @NM_PLUGIN_OPTION@.
* configure: Regenerated.
* configure.ac: Include config/clang-plugin.m4.
Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set
PLUGIN_OPTION. Set and subst NM_PLUGIN_OPTION.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use CLANG_PLUGIN_FILE and
GCC_PLUGIN_OPTION.
PR binutils/33470
* aclocal.m4: Regenerated.
* configure: Likewise.
* configure.ac: Move GCC_PLUGIN_OPTION after GCC_NO_EXECUTABLES.
Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set
PLUGIN_OPTION. Don't add the redundant --plugin option.
PR ld/33456
* elflink.c (elf_link_add_object_symbols): Move new check later
to give the backend add_symbol_hook a chance to remove symbols
with empty names.
Alan Modra [Wed, 24 Sep 2025 22:52:24 +0000 (08:22 +0930)]
PR 33452 SEGV in bfd_elf_gc_record_vtentry
Limit addends on vtentry relocs, otherwise ld might attempt to
allocate a stupidly large array. This also fixes the expression
overflow leading to pr33452. A vtable of 33M entries on a 64-bit
host is surely large enough, especially considering that VTINHERIT
and VTENTRY relocations are to support -fvtable-gc that disappeared
from gcc over 20 years ago.
Andrew Burgess [Wed, 10 Sep 2025 13:54:21 +0000 (14:54 +0100)]
gdb/linux: consider ptrace_scope when building attach error message
On GNU/Linux, if an attach fails, then we end up calling
linux_ptrace_attach_fail_reason, which returns a string describing why
the attach might have failed.
This commit extends linux_ptrace_attach_fail_reason to check the
current /proc/sys/kernel/yama/ptrace_scope setting. When this is set
to a value greater than 0 attaching can be restricted in some cases.
If I first set ptrace_scope to 1, like this:
$ echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope
Then use current master GDB to attach to a process, I see this:
(gdb) attach 2476518
Attaching to process 2476518
ptrace: Operation not permitted.
(gdb)
With this patch applied the output becomes:
(gdb) attach 2476518
Attaching to process 2476518
warning: the /proc/sys/kernel/yama/ptrace_scope setting of 1 might prevent attaching, see 'man 2 ptrace'
ptrace: Operation not permitted.
(gdb)
In my (limited) experience, not every user is familiar with the
ptrace_scope setting. Finding that attach just doesn't work often
leads users to believe that the only way to have GDB attach to another
process is to run GDB as root.
Though that is a solution to the problem, my hope is that, by giving
the users more information, they can make a more informed choice about
which solution is right for them (e.g. run as root, change the
setting, start the inferior directly under GDB, etc).
This change also works for gdbserver. For example:
(gdb) target extended-remote :54321
Remote debugging using :54321
(gdb) attach 2475389
Attaching to process 2475389
Attaching to process 2475389 failed: Cannot attach to process 2475389: \
Operation not permitted (1), the /proc/sys/kernel/yama/ptrace_scope \
setting of 1 might prevent attaching, see 'man 2 ptrace'
(gdb)
There's no test for this as testing would require adjusting a system
wide setting.
I've linked to a semi-related bug. It is discussing the same issue at
least. This patch doesn't try to "fix" anything that the bug is
talking about, it just makes it (I think) slightly clearer when the
issue does arise.
Timur Golubovich [Thu, 28 Aug 2025 17:12:55 +0000 (20:12 +0300)]
This commit adds support for catching syscalls on riscv
It affects following files:
- gdb/riscv-linux-tdep.c: a function to get syscall number.
- gdbserver/linux-riscv-low.cc: syscall trapinfo function to enable
catching syscalls on remote targets.
- gdb/syscalls/riscv-linux.xml.in: a file with syscalls, generated from
linux kernel sources using gdb/syscalls/update-linux-from-src.sh script.
- gdb/syscalls/riscv-linux.xml: a file with syscalls, patched with group
names gdb/syscalls/apply-defaults.xsl using xsltproc tool.
- gdb/syscalls/update-linux.sh: set startyear to 2025 on riscv.
- gdb/syscalls/update-linux-from-src.sh: riscv syscall table must be
generated from kernel headers.
- gdb/NEWS: catch-syscall feature is now available on riscv.
- gdb/data-directory/Makefile.in: adding file with syscalls to Makefile.
Stephan Rohr [Wed, 20 Aug 2025 13:06:23 +0000 (06:06 -0700)]
gdb: resolve type to target_type in expression evaluation
If an expression is evaluated with 'EVAL_AVOID_SIDE_EFFECTS', we're
essentially interested in compatibility of the operands. If there is an
operand of reference type, this would give us a memory value that would
cause a failure if GDB attempts to access the contents.
GDB fails to evaluate binary expressions for the following example:
Expression evaluation uses helper functions such as 'value_equal',
'value_logical_not', etc. These helper functions do not take a 'noside'
argument and if one of their value arguments was created from a function
call that returns a reference type when noside == EVAL_AVOID_SIDE_EFFECTS,
GDB attempts to read from an invalid memory location. Consider the
following call stack of the 'ptype v_struct.get () + 1' command at the time
of assertion when the memory error is raised:
#0 memory_error (err=TARGET_XFER_E_IO, memaddr=0) at gdb/corefile.c:114
#1 read_value_memory (val=.., bit_offset=0, stack=false, memaddr=0,
buffer=.. "", length=4) at gdb/valops.c:1075
#2 value::fetch_lazy_memory (this=..) at gdb/value.c:3996
#3 value::fetch_lazy (this=..) at gdb/value.c:4135
#4 value::contents_writeable (this=..) at gdb/value.c:1329
#5 value::contents (this=..) at gdb/value.c:1319
#6 value_as_mpz (val=..) at gdb/value.c:2685
#7 scalar_binop (arg1=.., arg2=.., op=BINOP_ADD) at gdb/valarith.c:1240
#8 value_binop (arg1=.., arg2=.., op=BINOP_ADD) at gdb/valarith.c:1489
#9 eval_op_add (expect_type=0x0, exp=.., noside=EVAL_AVOID_SIDE_EFFECTS,
arg1=.., arg2=..) at gdb/eval.c:1333
#10 expr::add_operation::evaluate (this=.., expect_type=0x0, exp=..,
noside=EVAL_AVOID_SIDE_EFFECTS) at gdb/expop.h:1209
#11 expression::evaluate (this=.., expect_type=0x0,
noside=EVAL_AVOID_SIDE_EFFECTS) at gdb/eval.c:110
#12 expression::evaluate_type (this=..) at gdb/expression.h:242
'add_operation::evaluate' calls the helper 'eval_op_add' which attempts
to read from the unresolved memory location. Convert to the target type
to avoid such problems. The patch is implemented in 'expop.h' for the
following reasons:
* Support templated classes without explicit helpers, e.g.,
'binop_operation' and 'comparison_operation'.
* Stripping references in 'binop_promote' requires additional
refactoring beyond this patch as we would need to carry on the
'noside' parameter.
The above failures are resolved with the patch:
(gdb) print v_struct.get () == 1 && v_struct3.get () == 2
$1 = false
(gdb) print v_struct.get () == 1 || v_struct3.get () == 2
$2 = true
(gdb) ptype v_struct.get ()
type = int &
(gdb) ptype v_struct.get () == 1
type = bool
(gdb) ptype v_struct.get () + 1
type = int
(gdb) ptype v_struct.get () && 1
type = bool
(gdb) ptype v_struct.get () || 1
type = bool
(gdb) ptype !v_struct.get ()
type = bool
(gdb) ptype v_struct.get () ? 2 : 3
type = int
(gdb) ptype v_struct.get () | 1
type = int
Co-Authored-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Wed, 24 Sep 2025 07:57:25 +0000 (09:57 +0200)]
[gdb/testsuite] Fix gdb.tui/tui-layout-asm-short-prog.exp on cygwin
On x86_64-cygwin, I run into:
...
Running tui-layout-asm-short-prog.exp ...
gdb compile failed, tui-layout-asm-short-prog.S: Assembler messages:
tui-layout-asm-short-prog.S:26: Error: \
junk at end of line, first unrecognized character is `-'
=== gdb Summary ===
# of untested testcases 1
...
This is due to this note in gdb.tui/tui-layout-asm-short-prog.S:
...
.section .note.GNU-stack,"",@progbits
...
The note can be easily skipped for cygwin, but after doing so, we run into a
fail.
The problem is that while the test-case tries to generate 5 nops:
...
.rept 5
nop
.endr
...
in fact 16 nops are generated.
The fail is not specific to x86_64-cygwin, if we do ".rept 16" on
x86_64-linux, we get the same fail.
Fix this by increasing the "large" scroll amounts from 13 to 15.
H.J. Lu [Tue, 23 Sep 2025 00:52:26 +0000 (08:52 +0800)]
elf: Return error on unsorted symbol table if not allowed
Normally ELF symbol table should be sorted, i.e., local symbols precede
global symbols. Irix 6 is an exception and its elf_bad_symtab is set
to true. Issue an error if elf_bad_symtab is false and symbol table is
unsorted.
PR ld/33450
* elflink.c (set_symbol_value): Change return type to bool and
return false on error. Issue an error on unsorted symbol table
if not allowed.
(elf_link_input_bfd): Return false if set_symbol_value reurns
false.
Alice Carlotti [Tue, 2 Sep 2025 15:30:16 +0000 (16:30 +0100)]
aarch64: Remove unused feature bits
Many feature bits were unnecessarily added for features with no command
line flags, and effectively acted as aliases of the architecture version
bit they were linked to. The system register regating patch removed all
uses of these feature bits, so we can just remove them.
Alice Carlotti [Tue, 2 Sep 2025 14:45:39 +0000 (15:45 +0100)]
aarch64: Update system register gating
Historically we have been inconsistent and overly restrictive in our
choice of features to gate system register accesses. (Originally this
gating was always applied, but now it is disabled unless the
--menable-sysreg-checking option is specified).
This patch updates these constraints, following the principle that we
should only reject a system register access if it requires some
architecture feature or version whose corresponding command line
extension has not been enabled.
The most common change in this patch concerns system registers that
were:
- part of a feature FEAT_X with no corresponding command line extension;
- introduced in a newer architecture version ArmvX.Z;
- permitted to be implemented from an earlier version ArmvX.Y.
Previously these system registers tended to be gated on ArmvX.Z or left
ungated, but following the above principle they are now gated on ArmvX.Y
instead.
Alice Carlotti [Tue, 2 Sep 2025 16:46:01 +0000 (17:46 +0100)]
aarch64: Remove CSRE system registers
Most support for CSRE was removed from Binutils in 2021 after it was
removed from the architecture. This patch removes the remaining system
registers and test files.
Alice Carlotti [Tue, 2 Sep 2025 14:49:40 +0000 (15:49 +0100)]
aarch64: Make spmzr_el0 write-only
Remove all test cases that expect spmzr_el0 to be readable, and remove
some redundant default macro values from armv9_5-a-sysregs.s while we're
there.
Add a read of spmzr_el0 to sysreg-diagnostics.s. This turns out to be
the first test for the "reading from a write-only register" note.
Also remove the recently added -menable-sysreg-checking option from this
test, both to simplify the addition of spmzr_el0 to the test, and to
verify that read/write diagnostics don't depend on that option.
Alice Carlotti [Tue, 2 Sep 2025 14:11:24 +0000 (15:11 +0100)]
aarch64: Remove F_ARCHEXT flag
The flag is unnecessary, because we can just unconditionally check the
features field every time. Having the information duplicated in two
separate fields makes it harder to maintain, particularly in the context
of the upcoming regating patch.
The reg_flags parameter of aarch64_sys_ins_reg_supported_p is now
unused, so remove that as well.
#5 0x000055a21da8a880 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=problem@entry=0x55a21e289060 <internal_error_problem>, file=<optimized out>, line=<optimized out>, fmt=<optimized out>, ap=ap@entry=0x7ffec7576be0) at ../../gdb/utils.c:477
#6 0x000055a21da8aadf in internal_verror (file=<optimized out>, line=<optimized out>, fmt=<optimized out>, ap=ap@entry=0x7ffec7576be0) at ../../gdb/utils.c:503
#7 0x000055a21dcbd055 in internal_error_loc (file=file@entry=0x55a21dd33b71 "../../gdb/regcache.c", line=line@entry=432, fmt=<optimized out>) at ../../gdbsupport/errors.cc:57
#8 0x000055a21d8baaa9 in get_thread_regcache (thread=thread@entry=0x55a258de3a50) at ../../gdb/regcache.c:432
#9 0x000055a21d74fa18 in print_signal_received_reason (uiout=0x55a258b649b0, siggnal=GDB_SIGNAL_TRAP) at ../../gdb/infrun.c:9287
#10 0x000055a21d7daad9 in mi_interp::on_signal_received (this=0x55a258af5f60, siggnal=GDB_SIGNAL_TRAP) at ../../gdb/mi/mi-interp.c:372
#11 0x000055a21d76ef99 in interps_notify<void (interp::*)(gdb_signal), gdb_signal&> (method=&virtual table offset 88, this adjustment 974682) at ../../gdb/interps.c:369
#12 0x000055a21d76e58f in interps_notify_signal_received (sig=<optimized out>, sig@entry=GDB_SIGNAL_TRAP) at ../../gdb/interps.c:378
#13 0x000055a21d75074d in notify_signal_received (sig=GDB_SIGNAL_TRAP) at ../../gdb/infrun.c:6818
#14 0x000055a21d755af0 in normal_stop () at ../../gdb/gdbthread.h:432
#15 0x000055a21d768331 in fetch_inferior_event () at ../../gdb/infrun.c:4753
The user is using a build of GDB with 32-bit ARM support included, and
they gave the following description for what they were doing at the
time of the crash:
Suspended the execution of the firmware in Eclipse. The gdb was
connected to JLinkGDBServer with activated FreeRTOS awareness JLink
plugin.
So they are remote debugging with a non-gdbserver target.
Looking in normal_stop() we see this code:
/* As we're presenting a stop, and potentially removing breakpoints,
update the thread list so we can tell whether there are threads
running on the target. With target remote, for example, we can
only learn about new threads when we explicitly update the thread
list. Do this before notifying the interpreters about signal
stops, end of stepping ranges, etc., so that the "new thread"
output is emitted before e.g., "Program received signal FOO",
instead of after. */
update_thread_list ();
Which accounts for the transition from frame #14 to frame #13. But it
is the update_thread_list() call which interests me. This call asks
the target (remote target in this case) for the current thread list,
and then marks threads exited based on the answer.
And so, if a (badly behaved) target (incorrectly) removes a thread
from the thread list, then the update_thread_list() call will mark the
impacted thread as exited, even if GDB is currently handling a signal
stop event for that target.
My guess for what's going on here then is this:
1. Thread receives a signal.
2. Remote target sends GDB a stop with signal packet.
3. Remote decides that the thread is going away soon, and marks the
thread as exited.
4. GDB asks for the thread list.
5. Remote sends back the thread list, which doesn't include the
event thread, as the remote things this thread has exited.
6. GDB marks the thread as exited, and then proceeds to try and
print the signal stop event for the event thread.
7. Printing the signal stop requires reading registers, which
requires a regache. We can only get a regcache for a non-exited
thread, and so GDB raises an assertion.
Using the gdbreplay test frame work I was able to reproduce this
failure using gdbserver. I create an inferior with two threads, the
main thread sends a signal to the second thread, GDB sees the signal
arrive and prints this information for the user.
Having captured the trace of this activity, I then find the thread
list reply in the log file, and modify it to remove the second thread.
Now, when I replay the modified log file I see the same assertion
complaining about an attempt to get a regcache for an exited thread.
I'm not entirely sure the best way to fix this. Clearly the problem
here is a bad remote target. But, replies from a remote target
should (in my opinion) not be considered trusted, as a consequence, we
should not be asserting based on data coming from a remote. Instead,
we should be giving warnings or errors and have GDB handle the bad
data as best it can.
This is the second attempt to fix this issue, my first patch can be
seen here:
In the first patch I was to checking in normal_stop, immediately after
the call to update_thread_list, to see if the current thread was now
marked as exited. However CI testing showed an issue with this
approach; I was already checking for many different TARGET_WAITKIND_*
kinds where the "is the current thread exited" question didn't make
sense, and it turns out that the list of kinds in my first attempt was
already insufficient.
Rather than trying to just adding to the list, in this revised patch
I'm proposing to move the "is this thread exited" check inside the
block which handles signal stop events.
Right now, the only part of normal_stop which I know relies on the
current thread not being exited is the call to notify_signal_received,
so before calling notify_signal_received I check to see if the current
thread is now exited. If it is then I print a warning to indicate
that the thread has unexpectedly exited and that the current
command (continue/step/etc) has been cancelled, I then change the
current event type to TARGET_WAITKIND_SPURIOUS.
GDB's output now looks like this in all-stop mode:
The non-stop output is identical, except we don't switch thread (stop
events never trigger a thread switch in non-stop mode).
The include test makes use of the gdbreplay framework, and tests in
all-stop and non-stop modes. I would like to do more extensive
testing of GDB's state after the receiving the unexpected thread list,
but due to using gdbreplay for testing, this is quite hard. Many
commands, especially those looking at thread state, are likely to
trigger additional packets being sent to the remote, which causes
gdbreplay to bail out as the new packet doesn't match the original
recorded state. However, I really don't think it is a good idea to
change gdbserver in order to "fake" this error case, so for now, using
gdbreplay is the best idea I have.
Andrew Burgess [Fri, 1 Aug 2025 11:26:41 +0000 (12:26 +0100)]
gdbserver: better handling for missing argument values
By passing ':' within the optstring to getopt_long, the getopt_long
call will now return ':' for missing value errors and '?' for unknown
argument errors, rather than returning '?' for all error types.
We can now print a different error message for missing argument
values. For example:
$ gdbserver --debug-file :54321 /tmp/hello
Missing argument value for: --debug-file
Andrew Burgess [Fri, 1 Aug 2025 11:22:38 +0000 (12:22 +0100)]
gdbserver: allow gnu style arguments to gdbserver
Now that we use getopt_long for argument processing in gdbserver, it
is relatively easy to support GNU style arguments, that is, arguments
passed without an '=' between the argument and the value.
As support for GNU style arguments is the default from getopt_long,
the first part of this commit is to remove the code which deliberately
disables the GNU argument support.
With that done, we now need to consider optional arguments. In this
case, getopt_long doesn't automatically grab the next word from ARGV
to be the argument value, so I've added some code to do this.
I've also tried to make this code a little smart. As the first
argument passed to gdbserver that doesn't have a '--' at the start is
the PORT number, the new code block I've added tries to spot if the
argument value might be the port number. If it is, then we don't
allow the port number to become the argument value, and instead, we
pretend the argument value is missing. This seems to give better
error messages.
There are going to be UI changes in how gdbserver handles incorrect
arguments after this commit. However, the behaviour for valid
command lines should be unchanged.
Support the fs_base and gs_base registers on i386.
So the SSP overlap is new, but the fs/gs base overlap has existed for
years, so why did it not cause any problems?
I think the explanation is that on i386, the fs/gs base are only used
for FreeBSD, all the calls to i386_target_description that pass true
for the segments argument are from fbsd files. As a result, its fine
if there's numbering overlap between these i386 registers and some
Linux specific i386 registers.
OK, but what about the new SSP (shadow stack pointer) register?
I think in this case we would see problems, if the shadow stack was
supported for i386. Here's what the docs say:
The ‘org.gnu.gdb.i386.pl3_ssp’ feature is optional. It should
describe the user mode register ‘pl3_ssp’ which has 64 bits on amd64, 32
bits on amd64 with 32-bit pointer size (X32) and 32 bits on i386.
Following the restriction of the Linux kernel, only GDB for amd64
targets makes use of this feature for now.
And indeed, if we look for callers of x86_supply_ssp, which supplies
the shadow stack pointer register, this is only called from amd64
specific code, either the native register fetching, or the core file
loading. There's no calls from i386 code.
And so, again, we have register number overlap, but we avoid any
issues by not making use of these registers for i386 linux.
Here's my question: Is this super clever design aimed at saving 12
bytes (3 * 4-byte registers) of space in the i386 regcache? Or is
this an accident where we happen to have gotten lucky?
If it's the first, then I really think there should be some comments
explaining what's going on.
If it's the second, then maybe we should fix this before it trips us
up?
This commit takes the second approach by doing the following:
1. In i386-tdep.h move all the *_NUM_REGS constants to be members of
'enum i386_regnum'. The I386_NUM_REGS value can be automatically
calculated based off the (current) last enum entry, and the
other *_NUM_REGS constants are calculated just as they previously
were, but are moved to keep them all together.
2. In i386-linux-tdep.h, I386_LINUX_ORIG_EAX_REGNUM and
I386_LINUX_NUM_REGS are moved into a new enum i386_linux_regnum,
the name of which is inspired by i386_regnum with the addition
of the linux tag. The first entry in this new enum starts from
I386_NUM_REGS rather than I386_PKRU_REGNUM. The
I386_LINUX_NUM_REGS will be calculated automatically by the
compiler.
3. In amd64-linux-nat.c, I extend amd64_linux_gregset32_reg_offset
so that it now has entries for the 3 registers that are no longer
aliasing, this stops an assert from the end of the file
triggering:
4. Given (3) I wondered why there was no assert being triggered from
the i386 code as i386_linux_gregset_reg_offset, in i386-linux-tdep.c
is clearly also wrong now.
So, In i386-linux-tdep.c I've added a new assertion at the end of
the file.
And then I've fixed i386_linux_gregset_reg_offset by adding the 3
new registers.
With these changes made I believe that the register number for the
$orig_eax register on i386 GNU/Linux targets should no longer be
aliasing with the SSP register.
For the reasons given above, I don't think this fixes any actual bugs,
it's more just a, lets not have unnecessary, and undocumented,
register number aliasing.
This change is visible using 'maint print registers', check out the
register number of $orig_eax before and after, it should now be +3
from where it was (changed from 72 to 75).
I did worry briefly about gdbservers that might not support XML target
descriptions and instead rely on a fixed GDB register numbering.
Though, if I'm honest, I have very little sympathy for such gdbservers
these days. Still, they could, potentially be tripped up by this
change. However, this is not the first time in recent years that the
value of I386_LINUX_ORIG_EAX_REGNUM has changed. This commit also
adjusted the register number:
Add support for Intel PKRU register to GDB and GDBserver.
And I'm not aware of any bug reports that came from this, we certainly
didn't feel the need to adjust the register number back again. So I'm
guessing that this renumbering will also go without issue.
Other than that, there should be no user visible changes after this
commit.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Pedro Alves [Tue, 23 Sep 2025 10:40:27 +0000 (11:40 +0100)]
Adjust gdb.base/memops-watchpoint.exp for native Windows
On native Windows, I see:
continue
Continuing.
Thread 1 hit Hardware watchpoint 2: -location a[28]
Old value = 104 'h'
New value = 0 '\000'
0x00007ffe640a9953 in msvcrt!memmove () from C:\Windows\System32\msvcrt.dll
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
... two more of the same ...
This fails for a few reasons:
1) thread_prefix_re
The thread_prefix_re regexp doesn't handle the case of a thread with
no name:
set thread_prefix_re "(?:Thread $::decimal \[^\r\n\]* hit )?"
^ ^
Note how it expects two spaces between the thread number and the
"hit" word.
Fix it by dropping one of the spaces in the regexp.
2) libc vs msvcrt.dll
This:
-re ".*${function_re}.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
is expecting that the function exists in libc, which is not the case
on Windows.
Fix it by not expecting any particular library name.
3) endline consumed when it shouldn't
All these patterns:
-re ".*${function_re}.* \\(\\) at .*:$::decimal\r\n" {
-re ".*${function_re}.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
-re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" {
... consume the \r\n, and then do exp_continue, expecting that
eventually the:
-re -wrap "" {
... pattern matches. However, if the \r\n is already consumed, then
-wrap doesn't work, because that expects "\r\n$gdb_prompt ".
This wasn't noticed on Linux because there GDB prints at least one
more line before the prompt:
Old value = 104 'h'
New value = 0 '\000'
__memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:171
warning: 171 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory
(gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
...
Old value = 100 'd'
New value = 114 'r'
__memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:272
272 in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memmove watchpoint hits
...
Fix it by expecting but not consuming the endlines.
4) msvcrt.dll implements memset with memmove
Note how we are expecting a memset hit, but we get a memmove:
0x00007ffe640a9953 in msvcrt!memmove () from C:\Windows\System32\msvcrt.dll
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
We already handle memcpy implemented with memmove and vice versa.
Fix it by handling memset implemented with memmove in the same way.
With all these fixed, the test now passes cleanly on native Windows.
It still passes cleanly on GNU/Linux.
Pedro Alves [Tue, 11 Feb 2025 14:43:39 +0000 (14:43 +0000)]
Adjust gdb.base/memops-watchpoint.exp for Cygwin/Windows
When testing gdb.base/memops-watchpoint.exp on Cygwin, I see:
...
continue
Continuing.
Thread 1 "memops-watchpoint" hit Hardware watchpoint 2: -location a[28]
Old value = 104 'h'
New value = 0 '\000'
memset () at /usr/src/debug/cygwin-3.5.4-1/winsup/cygwin/x86_64/memset.S:68
68 rep stosq
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
Etc.
This fails on Windows because there all inferiors are multi-threaded
(because both Windows and the Cygwin runtime spawn helper threads), so
we always see the
'Thread N "foo" hit'
prefix, which the testcase isn't expecting.
Fix it by optionally expecting such the "Thread ... hit" prefix bit.
Pedro Alves [Tue, 23 Sep 2025 09:38:22 +0000 (10:38 +0100)]
Skip gdb.base/libsegfault.exp on Windows
Running gdb.base/libsegfault.exp on Cygwin/MSYS2 causes badness.
E.g. on Cygwin:
$ make check-parallel TESTS="gdb.base/libsegfault.exp"
...
Running /home/alves/gdb/src/gdb/testsuite/gdb.base/libsegfault.exp ...
0 [main] expect 6611 C:\cygwin64\bin\expect.exe: *** fatal error in forked process - error while loading shared libraries: libSegFault.so: cannot open shared object file: No such file or directory
*** starting '"C:\cygwin64\bin\dumper.exe" -n "C:\cygwin64\bin\expect.exe" 8012' for pid 6611, tid 7992
*** continuing pid 6611
parent: sync byte write: broken pipe
make[1]: *** [Makefile:320: check/gdb.base/libsegfault.exp] Error 255
make[1]: Target 'do-check-parallel' not remade because of errors.
make[1]: Leaving directory '/home/alves/gdb/build-cygwin-testsuite'
outputs/gdb.base/libsegfault/gdb.sum: no recognised summary line
outputs/gdb.base/libsegfault/gdb.log: no recognised summary line
make: *** [Makefile:260: check-parallel] Error 2
$
I.e., Expect's spawn fails, and that brings down the whole Expect
process. The result is that in serial mode, the test run just stops.
And in parallel mode we end up with incomplete gdb.sum/gdb.log files,
which dg-extract-results.sh can't process.
Since libSegFault.so is a glibc feature that doesn't exist on
Cygwin/MSYS2, just skip the test there.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I44bdbffa25a5d21c5019418b68776d334a57be26
Tom Tromey [Sat, 6 Sep 2025 18:30:35 +0000 (12:30 -0600)]
Update HFILES_NO_SRCDIR in gdb/Makefile.in
I noticed a header file from dwarf2/ was missing from HFILES_NO_SRCDIR
in gdb/Makefile.in. Looking more, I found many missing files. This
patch adds them all and sorts the list -- using "sort", though, and
not the advice at the top of Makefile.in that, IMO, seems hard to
implement.
This also removes some code from the 'tags' rule that I think is
obsolete.
Andrew Burgess [Sun, 7 Jan 2024 13:46:29 +0000 (13:46 +0000)]
gdb: new maintenance command to help debug remote argument issues
Add a new maintenance command 'maint test-remote-args', this command
takes an argument string and splits it using gdb::remote_args::split
and then joins the result using gdb::remote_args::join and prints all
of the results. This is useful for diagnosing problems with remote
argument passing.
This new command is identical to what the remote argument self-tests
do, but while I was working on improving remote argument passing it
was far easier to have a command that I could just throw example
strings at, rather than having to add new selftests and recompile
GDB.
I ended up adding a couple of additional helper functions to the
gdb::argv_vec class.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Tested-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Kevin Buettner <kevinb@redhat.com>
Tom de Vries [Sat, 20 Sep 2025 12:48:57 +0000 (14:48 +0200)]
[gdb/testsuite] Fix hardcoded constant in gdb.python/py-pp-maint.exp
In test-case gdb.python/py-pp-maint.exp, I came across:
...
gdb_test "disable pretty-printer global lookup_function_lookup_test" \
"1 printer disabled.*[expr $num_pp - 1] of $num_pp printers enabled"
gdb_test "disable pretty-printer global pp-test;.*" \
"[expr 5] printers disabled.*0 of $num_pp printers enabled"
...
The "[expr 5]" can simply be rewritten as "5", but instead use the construct
used in the previous gdb_test: [expr {$num_pp - 1}], given that the numbers
should match.
Simon Marchi [Fri, 19 Sep 2025 20:44:14 +0000 (16:44 -0400)]
gdb: make gcore-1.in and gstack-1.in shellcheck-clean
Fix all the warnings pasted below, mostly by accepting shellcheck's
suggestions.
The only exception is $GDBARGS in gstack. There, we actually want the
space-splitting, I suppose, so I chose to just ignore the warning on
that line. In any case, I'm not looking to change the existing behavior
in this patch.
The warnings:
$ shellcheck gstack-1.in gcore-1.in
In gstack-1.in line 135:
"$GDB" --quiet -nx $GDBARGS <<EOF |
^------^ SC2086 (info): Double quote to prevent globbing and word splitting.
Did you mean:
"$GDB" --quiet -nx "$GDBARGS" <<EOF |
In gcore-1.in line 130:
binary_path=`dirname "$0"`
^------------^ SC2006 (style): Use $(...) notation instead of legacy backticks `...`.
Did you mean:
binary_path=$(dirname "$0")
In gcore-1.in line 132:
if test "x$binary_path" = x. ; then
^-------------^ SC2268 (style): Avoid x-prefix in comparisons as it no longer serves a purpose.
Did you mean:
if test "$binary_path" = . ; then
In gcore-1.in line 136:
binary_basename=`basename "$0"`
^-------------^ SC2006 (style): Use $(...) notation instead of legacy backticks `...`.
Did you mean:
binary_basename=$(basename "$0")
In gcore-1.in line 150:
binary_path_from_env=`which "$0"`
^----------^ SC2006 (style): Use $(...) notation instead of legacy backticks `...`.
Did you mean:
binary_path_from_env=$(which "$0")
In gcore-1.in line 151:
binary_path=`dirname "$binary_path_from_env"`
^-- SC2006 (style): Use $(...) notation instead of legacy backticks `...`.
Did you mean:
binary_path=$(dirname "$binary_path_from_env")
In gcore-1.in line 159:
gdb_binary_basename=`basename "$gdb_binary"`
^----------------------^ SC2006 (style): Use $(...) notation instead of legacy backticks `...`.
Did you mean:
gdb_binary_basename=$(basename "$gdb_binary")
For more information:
https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
https://www.shellcheck.net/wiki/SC2006 -- Use $(...) notation instead of le...
https://www.shellcheck.net/wiki/SC2268 -- Avoid x-prefix in comparisons as ...
Change-Id: I0eeaf5dc968df1ebafce58d9a9053d149f7f7859 Reviewed-By: Sébastien Darche <sdarche@efficios.com> Reviewed-By: Keith Seitz <keiths@redhat.com>
Simon Marchi [Fri, 19 Sep 2025 20:44:13 +0000 (16:44 -0400)]
gdb: fix long options with arguments in gcore-1.in and gstack-1.in
Shellcheck 0.11.0 produces the same warning for gcore-1.in and
gstack-1.in:
In gcore-1.in line 74:
OPTARG="${OPTARG#'$OPT'}"
^----^ SC2016 (info): Expressions don't expand in single quotes, use double quotes for that.
In gstack-1.in line 67:
OPTARG="${OPTARG#$OPT}"
^--^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
The code in question exists to handle long option with arguments by
hand, like `--foo=bar`, since that is not supported natively by getopts.
At that line, OPTARG would contain `foo=bar`, OPT would contain `foo`,
and we're trying to strip `$OPT` from the beginning of `$OPTARG`. For
this to work, OPT needs to be expanded, and therefore needs double
quotes (or no quotes at all, but then shellcheck complains).
This bug is harmless right now because we don't use long options with
arguments. I tested this by temporarily making gcore support
-o|--output:
Pedro Alves [Mon, 8 Sep 2025 19:10:22 +0000 (20:10 +0100)]
New '--binary-output' command line option, fix gdb.mi/ testing on Windows
MI testcases currently all fail on native Windows with:
Running /c/gdb/src/gdb/testsuite/gdb.mi/mi-simplerun.exp ...
ERROR: (timeout) GDB never initialized after 10 seconds.
This is because when GDB is started in MI mode, it prints info to the
terminal before -iex options are processed. I.e., before the "maint
set console-translation-mode binary" command in
... is processed. This results in GDB printing early output with
\r\r\n, like can be easily seen by passing --debug to runtest:
expect: does "=thread-group-added,id="i1"\r\r\n=cmd-param-changed,param="width",value="4294967295"\r\r\n=cmd-param-changed,param="interactive-mode",value="on"\r\r\n(gdb) \r\n" (spawn_id exp10) match regular expression "~"GNU.*\r\n~".*[(]gdb[)] \r\n$"? Gate "~"GNU*\r\n~"*gdb? \r\n"? gate=no
Fix this by adding a new Windows-only --binary-output command line
option to GDB, which is processed much earlier than -iex, and making
the testsuite pass that instead of "maint set console-translation-mode
binary".
Remove "maint set console-translation-mode" completely, since the only
reason it existed was for the testsuite, and it was never included in
any release.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tom de Vries <tdevries@suse.de>
Change-Id: I4632707bb7c8ca573cffff9641ddeb33a0e150af
Tom Tromey [Fri, 22 Aug 2025 17:52:26 +0000 (11:52 -0600)]
Change DAP condition for Ada exception catchpoint
Currently, the gdb DAP implementation doesn't provide a way to filter
based on the thrown Ada exception.
There isn't really an ideal way to handle this in DAP:
* Requiring an IDE to use an expression checking $_ada_exception
exposes the IDE to any workarounds needed to get this correct (see
ada-lang.c).
* The setExceptionBreakpoint "filterOptions" field doesn't allow a
special kind of condition to be set. (We could add one but we've
generally avoided gdb-specific extensions.)
* The "exceptionOptions" approach is under-documented. It could be
used but it would have to be in a somewhat gdb-specific way anyway
-- and this approach does not allow a separate condition that is an
expression.
So, after some internal discussion, we agreed that it isn't all that
useful to have conditions on Ada exception catchpoints. This patch
changes the implementation to treat the condition as an exception name
here.
In the original GAS bug, the first directory table entry did not contain
the current directory of the compilation. So the above commit added a
workaround fix to prepend the second directory table entry.
However recent Go toolchain compilations (specifically on aarch64)
only output a single directory table entry. Looking at the workaround:
if (lh->version == 5 && lh->is_valid_file_index (1))
{
std::string dir = lh->include_dir_at (1);
fnd.set_comp_dir (std::move (dir));
}
`lh->is_valid_file_index (1)' is true, but since the directory table only
has one entry, `include_dir_at (1)' returns nullptr. Consequently the
std::string ctor will segfault. Since there are no guarantees that the file
and directory tables are the same size, a better bounds check is to simply
rely on `include_dir_at' to ensure a valid directory table entry.
I have updated the workaround commit's test, gdb.dwarf2/dw2-gas-workaround.exp
and tested on x86_64 and aarch64 RHEL 9 and Fedora 41.
Tom de Vries [Fri, 19 Sep 2025 16:49:21 +0000 (18:49 +0200)]
[pre-commit] Update tclint to v6.0.1
Upstream tclint updated its stable release to v6.0.1. That version includes
the pre-commit support that was missing in v0.6.0, which required us to use an
unofficial repo [1].
Update tclint to v6.0.1.
Tested by running:
...
$ pre-commit run --all-files tclint
tclint................................................................Passed
...
Tom Tromey [Fri, 1 Aug 2025 18:46:18 +0000 (12:46 -0600)]
Handle Ada extended access thick pointers
In Ada, sometimes an array is represented as a "thick" pointer -- a
structure that holds a pointer to the array data and another pointer
to the bounds structure.
A new "extended access" feature is being added to GNAT which changes
the shape of these objects. With the new feature, the bounds are
inlined into the thick pointer.
This patch changes gdb to understand this new feature. A test case is
provided; it is written in C to avoid requiring a newer GNAT just for
this test.
Tom Tromey [Fri, 12 Sep 2025 17:49:40 +0000 (11:49 -0600)]
Handle optimized-out values in gdb.printing.make_visualizer
This changes gdb.printing.make_visualizer to treat an optimized-out
pointer as a scalar variable -- that is, one that does not advertise
any children. This makes sense because such a pointer cannot be
dereferenced.
The test case checks this case, plus it ensures that synthetic
pointers still continue to work.
Guinevere Larsen [Thu, 28 Aug 2025 13:40:34 +0000 (10:40 -0300)]
gdb/riscv/record: remove possibility of recording an empty instruction
When recording instructions in a riscv CPU, the function
riscv_process_record works in 2 steps: first, it disassembles the
current instruction and creates std::vectors with all the data that will
be changed (in the "record" method), and then those get added to the
history in a helper function. If the disassembly fails, the
process_record function will add a new "end instruction" marker to the
recorded history.
And that is where the issue happens. Because the previous instruction
must already have added an "end" marker and no new information has been
added, since it was only disassembly, the end result is having an empty
instruction in the history, which will be fully redundant. This commit
just removes the end marker addition.
Richard Earnshaw [Tue, 16 Sep 2025 15:47:55 +0000 (16:47 +0100)]
ld: testsuite: disambiguate sort_no tests.
The two tests sort_no-1.d and sort_no-2.d have the same test name.
They use the same options, but operate on different source files.
Annotate the second test so that it has a unique name.
Richard Earnshaw [Tue, 16 Sep 2025 15:45:21 +0000 (16:45 +0100)]
ld: testsuite: Fix test name in sort_b_n_a-2.d
This test was invoked with the option '--sort-section name' but the
test name printed out was '--sort-section alignment'. Fix the name to
match the option passed.
c: Update TLS model after processing a TLS variable
Set a tentative TLS model in grokvardecl and update TLS mode with
the default TLS access model after a TLS variable has been fully
processed if the default TLS access model is stronger,
triggered a linker error when building glibc using build-many-glibcs.py.
This is incorrect, because info could be invalid by the time
`info->name` gets evaluated. This trap was made possible by the fact
that the name is kept into lm_info_target, but then moved out of it.
lm_info_target::name is then no longer used.
Add a new `target_library` type, used to carry the name and
lm_info_target, while we parse the XML, until we build the struct solib
objects.
Change-Id: I0d745465021fca4da79659893562e1e9ffd04f57 Approved-By: Tom Tromey <tom@tromey.com>
Hui Li [Wed, 17 Sep 2025 08:39:06 +0000 (16:39 +0800)]
gdb: LoongArch: Record correct frame base address
(1) Description of Problem:
The frame_base structure is defined in gdb/frame-base.h, a typical
implementation of frame_base is return the same value for frame base,
locals base and args base. When debugging following code on LoongArch,
the outputs of locals base and args base are not equal to frame base
address in frame base register. The frame base register is sp(r3) or
fp(r22) on LoongArch. This problem only occurs when frame base register
is sp, there is no problem when fp is used as frame base register. When
using gcc option -fomit-frame-pointer or writing asm code without using
fp, the frame base register is sp.
$ cat test.c
int main()
{
unsigned long a= 1, b = 1;
a = 2;
b = 2;
return 0;
}
$ gcc -g -fomit-frame-pointer test.c -o test
$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:4
4 unsigned long a= 1, b = 1;
(gdb) disas
Dump of assembler code for function main:
0x0000555555554740 <+0>: addi.d $sp, $sp, -16
=> 0x0000555555554744 <+4>: li.w $t0, 1
0x0000555555554748 <+8>: st.d $t0, $sp, 8
0x000055555555474c <+12>: li.w $t0, 1
0x0000555555554750 <+16>: stptr.d $t0, $sp, 0
0x0000555555554754 <+20>: li.w $t0, 2
0x0000555555554758 <+24>: st.d $t0, $sp, 8
0x000055555555475c <+28>: li.w $t0, 2
0x0000555555554760 <+32>: stptr.d $t0, $sp, 0
0x0000555555554764 <+36>: move $t0, $zero
0x0000555555554768 <+40>: move $a0, $t0
0x000055555555476c <+44>: addi.d $sp, $sp, 16
0x0000555555554770 <+48>: ret
End of assembler dump.
(gdb) p $sp
$1 = (void *) 0x7ffffffeb130
(gdb) info frame
Stack level 0, frame at 0x7ffffffeb140:
pc = 0x555555554744 in main (test.c:4); saved pc = 0x7ffff7e3d874
source language c.
Arglist at 0x7ffffffeb140, args:
Locals at 0x7ffffffeb140, Previous frame's sp is 0x7ffffffeb140
(2) Root Cause Analysis:
When we use the info frame command, the addresses of previous frame's sp,
arglist and locals will be printed, the arglist and locals addresses are
calculated by member function of frame_base. Because LoongArch does not
implement its own frame_base, a default_frame_base will be used, it will
return stack address of the frame ID for frame base, locals base and args
base. However, on LoongArch or other architectures, the frame base address
does not always equal the stack address of the frame ID.
(3) Solution:
Implement loongarch_frame_base structure and loongarch_frame_base_address()
to record the correct frame base address stored in sp or fp register. It can
be calculated by subtracting the framebase_offset from the prev_sp recorded
in loongarch_frame_cache. And locals base and args base here are equal to
frame base.
(4) Test:
(gdb) p $sp
$1 = (void *) 0x7ffffffeb130
(gdb) info frame
Stack level 0, frame at 0x7ffffffeb140:
pc = 0x555555554744 in main (test.c:4); saved pc = 0x7ffff7e3d874
source language c.
Arglist at 0x7ffffffeb130, args:
Locals at 0x7ffffffeb130, Previous frame's sp is 0x7ffffffeb140
This modification only change the output of the info frame command when sp
is used as frame base register, and has no affect other functions of gdb on
LoongArch.
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tom Tromey [Wed, 17 Sep 2025 15:36:45 +0000 (09:36 -0600)]
Move isort config to pyproject.toml
My understanding is that pyproject.toml is the "new" way to configure
Python tools. Although setup.cfg can't yet be removed (flake8 has
some issue with pyproject.toml), we can move the isort config here.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Thu, 18 Sep 2025 11:55:38 +0000 (04:55 -0700)]
ld: Don't use -mdirect-extern-access for LoongArch
Don't check DIRECT_EXTERN_ACCESS_CFLAGS/NO_DIRECT_EXTERN_ACCESS_CFLAGS
for LoongArch since -mdirect-extern-access on LoongArch works only
without dynamic linker.
PR ld/33409
* testsuite/config/default.exp (DIRECT_EXTERN_ACCESS_CFLAGS):
Skip on LoongArch.
(NO_DIRECT_EXTERN_ACCESS_CFLAGS): Likewise.
projects / thirdparty / binutils-gdb.git / log
