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.
Tom de Vries [Thu, 18 Sep 2025 10:20:56 +0000 (12:20 +0200)]
[gdb/testsuite] Two tclint.toml exclude list updates
Because it's already tclint-clean, remove gdb.ctf from the exclude list in
tclint.toml.
While we're at it, divide the exclude list in two parts, TODO and IGNORE and
move gdb.stabs to the IGNORE part because those tests are about to be removed.
Tom de Vries [Thu, 18 Sep 2025 06:08:41 +0000 (08:08 +0200)]
[pre-commit] Add tclint hook
Add a pre-commit hook that enables tclint [1] (a Tcl linter) for the gdb
testsuite.
The pre-commit hook doesn't reference the official url, because that one
doesn't have pre-commit support yet [2].
Instead, it uses a fork on my personal github account. The fork contains a
tag v0.6.0-gdb, which is the official v0.6.0 release plus a commit adding a
.pre-commit-hooks.yaml file. Given that this is a personal github account, I
thought it would be safer to refer to the git SHA than to the tag.
Also add a tclint configuration file gdb/tclint.toml.
In the configuration file, we still ignore most dirs because they're not
tclint-clean.
GDB: aarch64: Use GCS features to calculate hash of struct aarch64_features
Luis noticed that when adding the gcs and gcs_linux members to struct
aarch64_features in my Guarded Control Stack patch series, I neglected to
modify struct hash<aarch64_features>::operator() to take them into account
when computing its hash.
This can cause GDB to use the wrong aarch64_features object during a
debugging session.
Regression tested on aarch64-linux-gnu.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33440 Suggested-by: Luis Machado <luis.machado.foss@gmail.com> Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Tom de Vries [Wed, 17 Sep 2025 17:07:43 +0000 (19:07 +0200)]
[gdb/testsuite, tclint] Fix gdb.dap
Running tclint on gdb.dap shows these warnings:
...
bt-nodebug.exp:74:16: namespace eval received an argument with a \
substitution, unable to parse its arguments [command-args]
eof.exp:33:1: expected braced word or word without substitutions in argument \
interpreted as script [command-args]
eof.exp:34:1: expected braced word or word without substitutions in argument \
interpreted as script [command-args]
...
The first one is for:
...
set list_form [namespace eval ton::2list $last_ton]
...
I don't think this can be fixed by rewriting into something similar, so ignore
this. Likewise in lib/dap-support.exp.
The second and third ones are for:
...
catch "close -i $gdb_spawn_id"
catch "wait -i $gdb_spawn_id"
...
which can easily be fixed by using curly braces instead of double quotes, but
doing so gets us:
...
eof.exp:33:8: unrecognized argument for close: -i [command-args]
...
This is because tclint doesn't have support for expect yet [1], so ignore this.
While we're at it, fix some trailing whitespace in lib/dap-support.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/nmoroze/tclint/issues/118
gdb/gdbserver: add a '--no-escape-args' command line option
Inferior argument handling on the GDB command line was broken:
$ gdb --args /bin/ls --foo
./gdb/gdb: unrecognized option '--foo'
./gdb/gdb: `--args' specified but no program specified
Before the above patch the definition of the '--args' argument in the
long_options array (in captured_main_1) was such that the
getopt_long_only call would directly set the 'set_args' variable to
true if '--args' was seen.
This meant that, immediately after the getopt_long_only call, we could
inspect set_args and break out of the argument processing loop if
needed.
After the above patch '--args' (and the new '--no-escape-args') no
longer set set_args directly via the getopt_long_only call. Instead
the getopt_long_only call returns an OPT_* enum value, which we then
use in the following switch statement in order to set the set_args
variable.
What this means is that, immediately after the getopt_long_only call,
set_args no longer (immediately) indicates if --args was seen. After
the switch statement, when set_args has been updated, we go around the
argument processing loop again and call getopt_long_only once more.
This extra getopt_long_only call will, if it finds another argument
that starts with a dash, update the global optind to point to this
option. At this point things have gone wrong, GDB has now lost track
of the argument containing the program name the user wanted us to
start. This leads to GDB exiting with the above error.
The solution is to move the check of set_args to either before the
getopt_long_only call, or to after the switch statement. I chose to
move it earlier as this keeps all the loop exiting checks near the
beginning.
I've added more tests that cover this issue.
Approved-By: Luis Machado <luis.machado.foss@gmail.com> Tested-By: Luis Machado <luis.machado.foss@gmail.com>
Tom de Vries [Tue, 16 Sep 2025 20:03:43 +0000 (22:03 +0200)]
[gdb/testsuite] Remove more uses of "eval"
Remove some more uses of the Tcl "eval" proc.
In most cases the {*} "splat" expansion is used instead.
The exceptions are:
- gdb.base/inferior-args.exp where we rewrite:
set cmd [format "lappend item \{ '%c' '\\%c' \}" 34 34]
eval $cmd
into:
lappend item [format { '%c' '\%c' } 34 34]
- reset_vars in lib/check-test-names.exp where we simply drop an unnecessary
eval
Richard Earnshaw [Tue, 16 Sep 2025 16:43:39 +0000 (17:43 +0100)]
ld: testsuite: arm: Fix duplicate test names.
Rename some tests to avoid ambiguity in the test names. I've changed several
of the Thumb2 BL testnames to more accurately reflect the nature of the tests
(some omitted 'bad' even when testing for errors, but that then led to other
naming conflicts...).
While I was debugging application using spike, openocd and baremetal gdb in
record mode I encountered with gdb internal error. The reason was that
minus_one_ptid had been passed to record_full_target::resume method. And in
this function, the assert worked in target_thread_architecture. So I added
a check before calling this function, that ptid is not minus_one_ptid.
Actually, minus_one_ptid here doesn't mean that an error has occured, but it
is just a define for RESUME_ALL.
(gdb) record
(gdb) si
../../gdb/process-stratum-target.c:32: internal-error: thread_architecture:
Assertion `inf != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
...
0x71463a _ZN22process_stratum_target19thread_architectureE6ptid_t
../../gdb/process-stratum-target.c:32
0x71463a _ZN22process_stratum_target19thread_architectureE6ptid_t
../../gdb/process-stratum-target.c:29
0x77131f _ZN18record_full_target6resumeE6ptid_ti10gdb_signal
../../gdb/record-full.c:1087
0x85a761 _Z13target_resume6ptid_ti10gdb_signal
../../gdb/target.c:2654
0x677aa9 do_target_resume
../../gdb/infrun.c:2631
0x6818b5 resume_1
../../gdb/infrun.c:2984
0x6828a8 resume
../../gdb/infrun.c:2997
0x682b13 keep_going_pass_signal
../../gdb/infrun.c:9144
0x682fd9 proceed_resume_thread_checked
../../gdb/infrun.c:3580
...
---------------------
Richard Earnshaw [Tue, 16 Sep 2025 15:08:12 +0000 (16:08 +0100)]
binutils: testsuite: fix duplicate testnames in readelf.exp
There are two places in readelf.exp where we generate duplicate
testnames.
The first is due to calling readelf_find_size twice with the same
iteration index (2). This is fixed by using 4 for the second
instance.
The other is at the end of readelf_thin_archive_test. This test calls
readelf_test before unconditionally passing. It happens to construct
exactly the same test name as readelf test (might not be a
coincidence), so we end up with a duplicate test. But it seems wrong
anyway to 'pass' a test that readelf_test might have failed, so simply
delete this duplicate pass entry.
Tom Tromey [Fri, 30 May 2025 16:16:24 +0000 (10:16 -0600)]
Treat attributes as code in DWARF assembler
The DWARF assembler treats the 'children' of a DIE as plain Tcl code,
evaluating it in the parent context.
I don't recall why, but when I wrote this code, I didn't do the same
thing for the attributes. Instead, there I implemented a special
syntax. I was looking at this today and wondered why I didn't just
use ordinary evaluation as well.
This patch implements this idea. Attributes are now evaluated as
plain code. This is a bit less "magical", is slightly shorter due to
lack of braces, and most importantly now allows comments in the
attributes section.
Note that some [subst {}] calls had to be added. This could be fixed
by changing DWARF expressions to also be plain Tcl code. I think that
would be a good idea, but I didn't want to tack it on here.
This patch requires the full ("DW_AT_...") name for attributes. I did
this to avoid any possibility of name clashes. I've long considered
that my original decision to allow short names for tags and attributes
was a mistake. It's worth noting that many existing tests already
used the long names here.
Most of this patch was written by script. The main changes are in
dwarf.exp, but as noted, there were some minor fixups needed in some
tests.
Also, after committing, 'git show' indicated some whitespace issues,
so I've gone through and "tabified" some things, which is why the
patch might be otherwise larger than it should be. (This was
discussed a bit during the v1 submission.)
Richard Earnshaw [Tue, 16 Sep 2025 14:37:18 +0000 (15:37 +0100)]
gas: testsuite: aarch64: Remove duplicate test from sv2p1-5.d
This test runs with the assembler options '-march=armv9.4-a' twice.
Looking at the related tests in this set, this appears to be redundant
rather than a typo, so remove the second run.
The problem is here (with --program-prefix=prefix-), from gdb.log:
gcore: GDB binary (/home/pedro/gdb/build-program-prefix/gdb/testsuite/../../gdb/prefix-gdb) not found
FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished
That is gcore (the script, not the GDB command) trying to run the
installed GDB:
if [ ! -f "$binary_path/@GDB_TRANSFORM_NAME@" ]; then
echo "gcore: GDB binary (${binary_path}/@GDB_TRANSFORM_NAME@) not found"
exit 1
fi
...
"$binary_path/@GDB_TRANSFORM_NAME@" </dev/null \
...
When running the testsuite with the just-built GDB, the GDB binary is
'gdb', not @GDB_TRANSFORM_NAME@.
Fix this by adding a new '-g gdb" option to the 'gcore' script, that
lets you override the GDB binary gcore runs, and then making
gdb.base/gcorebg.exp pass it to gcore. The GDB binary we're testing
is always in the $GDB global. This is similar to how it is already
possible to specify GDB's data directory with an option to gcore, and
then gdb.base/gcorebg.exp uses it.
NEWS and documentation changes included.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I6c60fba8768618eeba8d8d03b131dc756b57ee78
Pedro Alves [Mon, 15 Sep 2025 21:12:28 +0000 (22:12 +0100)]
Fix nested gdb_caching_proc with args
Commit d09eba07 ("Make get_compiler_info use gdb_caching_proc")
regressed some tests when you run them in isolation (as this depends
on the order the gdb_caching_proc procs' results are cached).
E.g.:
Running /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp ...
ERROR: tcl error sourcing /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp.
ERROR: tcl error code TCL WRONGARGS
ERROR: wrong # args: should be "gdb_real__get_compiler_info_1 language"
while executing
"gdb_real__get_compiler_info_1"
("uplevel" body line 1)
invoked from within
"uplevel 2 $real_name"
(procedure "gdb_do_cache_wrap" line 3)
invoked from within
"gdb_do_cache_wrap $real_name {*}$args"
(procedure "gdb_do_cache" line 98)
invoked from within
gdb.base/attach.exp triggers it too, for example.
This is actually a latent problem in gdb_do_cache_wrap, introduced in:
# Call proc real_name and return the result, while ignoring calls to pass.
-proc gdb_do_cache_wrap {real_name} {
+proc gdb_do_cache_wrap {real_name args} {
if { [info procs save_pass] != "" } {
return [uplevel 2 $real_name] <<<<<<<<<<<<<<<<<<<<<<< HERE
}
@@ -31,7 +31,7 @@ proc gdb_do_cache_wrap {real_name} {
rename pass save_pass
rename ignore_pass pass
- set code [catch {uplevel 2 $real_name} result]
+ set code [catch {uplevel 2 [list $real_name {*}$args]} result]
Missed updating the line marked with HERE above, to pass down $args.
So the case of a caching proc calling another caching proc with args
isn't handled correctly.
We could fix this by fixing the HERE line like so:
However, we have with_override nowadays that we can use here which
eliminates the duplicated logic, which was what was missed originally.
A new test that exposes the problem is added to
gdb.testsuite/gdb-caching-proc.exp.
This also adds a new test to gdb.testsuite/with-override.exp that I
think was missing, making sure that the inner foo override restores
the outer foo override.
Tested-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I8b2a7366bf910902fe5f547bde58c3b475bf5133
Richard Earnshaw [Mon, 15 Sep 2025 15:25:43 +0000 (16:25 +0100)]
gas: testsuite: all: Avoid clashing names in err-sizeof.s
The first junk test in this file was missing "junk" in the test name,
which resulted in a duplicate test name when comparing with the real
test on line 3.
Richard Earnshaw [Mon, 15 Sep 2025 14:52:23 +0000 (15:52 +0100)]
binutils: testsuite: avoid dup names when using multiple as: directives
binutils tests support running a test with distinct options to the
assembler by allowing
#as: <optset-1>
#as: <optset-2>
But results in both test runs using the same test name in the summary
file. This causes confusion if one test fails but the other doesn't
(and GCC's compare_tests script will diagnose this as an error). To
fix the ambiguity append the appropriate optset to the test name.
We only do this if a test has multiple runs in this way to avoid
causing every test result name to change.
Richard Earnshaw [Mon, 15 Sep 2025 14:48:57 +0000 (15:48 +0100)]
gas: testsuite: all: use unique test names for multibyte3 tests
There are two tests of the mutibyte3 source file, with different
options. As things stand this results in two distinct tests in the
logs with the same name. Avoid this by adding the optional testname
option to the second test.
Solaris/PowerPC was a shortlived Solaris port with limited hardware
support. It was released with Solaris 2.5.1 back in 1996, with support
removed again only a year later in Solaris 2.6. Since this is long
obsolete, this patch removes the remains of the support.
Tested by a cross to ppc-unknown-linux-gnu to ascertain the build didn't
get broken.
Pedro Alves [Thu, 11 Sep 2025 12:14:16 +0000 (13:14 +0100)]
Make get_compiler_info use gdb_caching_proc
While running tests on Windows with:
$ make check-parallel RUNTESTFLAGS="-v"
I noticed that get_compiler_info was invoking the compiler over and
over for each testcase, even though the result is supposed to be
cached.
This isn't normally very visible in gdb.log, because we suppress it
there:
# Run $ifile through the right preprocessor.
# Toggle gdb.log to keep the compiler output out of the log.
set saved_log [log_file -info]
log_file
...
I'm not sure it's a good idea to do that suppression, BTW. I was very
confused when I couldn't find the compiler invocation in gdb.log, and
it took me a while to notice that code.
The reason get_compiler_info in parallel mode isn't hitting the cache
is that in that mode each testcase runs under its own expect/dejagnu
process, and the way get_compiler_info caches results currently
doesn't handle that -- the result is simply cached in a global
variable, which is private to each expect.
So improve this by switching get_compiler_info's caching mechanism to
gdb_caching_proc instead, so that results are cached across parallel
invocations of dejagnu.
On an x86-64 GNU/Linux run with "make check-parallel -j32", before the
patch I get 2223 calls to get_compiler_info that result in a compiler
invocation. After the patch, I get 7.
On GNU/Linux, those compiler invocations don't cost much, but on
Windows, they add up. On my machine each invocation takes around
500ms to 700ms. Here is one representative run:
$ time x86_64-w64-mingw32-gcc \
/c/msys2/home/alves/gdb/build-testsuite/temp/14826/compiler.c \
-fdiagnostics-color=never -E
...
real 0m0.639s
user 0m0.061s
sys 0m0.141s
This reference to a 'compiler_info' global:
# N.B. compiler_info is intended to be local to this file.
# Call test_compiler_info with no arguments to fetch its value.
# Yes, this is counterintuitive when there's get_compiler_info,
# but that's the current API.
if [info exists compiler_info] {
unset compiler_info
}
is outdated, even before this patch, as "compiler_info" is a local
variable in get_compiler_info. Remove all that code.
Since test_compiler_info now calls get_compiler_info directly, the
"Requires get_compiler_info" comments in skip_inline_frame_tests and
skip_inline_var_tests are no longer accurate. Remove them.
test_compiler_info's intro comment is also outdated; improve it.
Changing the return value of get_compiler_info to be the
'compiler_info' string directly instead of 0/-1 was simpler. It would
be possible to support the current 0/-1 interface by making
get_compiler_info_1 still return the 'compiler_info' string, and then
having the get_compiler_info wrapper convert to 0/-1, and I considered
doing that. But the only caller of get_compiler_info outside gdb.exp
is gdb.python/py-event-load.exp, and it seems that one simply crossed
wires with:
as the test as added at roughly the same time as that commit.
So simply remove that call in gdb.python/py-event-load.exp, otherwise
we get something like:
ERROR: -------------------------------------------
ERROR: in testcase src/gdb/testsuite/gdb.python/py-event-load.exp
ERROR: expected boolean value but got "gcc-13-3-0"
ERROR: tcl error code TCL VALUE NUMBER
ERROR: tcl error info:
expected boolean value but got "gcc-13-3-0"
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ia3d3dc34f7cdcf9a2013f1054128c62a108eabfb
projects / thirdparty / binutils-gdb.git / log
