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
Simon Marchi [Wed, 20 Aug 2025 16:50:08 +0000 (12:50 -0400)]
gdbsupport: remove xmalloc in format_pieces
Remove the use of xmalloc (and the arbitrary allocation size) in
format_pieces. This turned out a bit more involved than expected, but
not too bad.
format_pieces::m_storage is a buffer with multiple concatenated
null-terminated strings, referenced by format_piece::string. Change
this to an std::string, while keeping its purpose (use the std::string
as a buffer with embedded null characters).
However, because the std::string's internal buffer can be reallocated as
it grows, and I do not want to hardcode a big reserved size like we have
now, it's not possible to store the direct pointer to the string in
format_piece::string. Those pointers would become stale as the buffer
gets reallocated. Therefore, change format_piece to hold an index into
the storage instead. Add format_pieces::piece_str for the callers to be
able to access the piece's string. This requires changing the few
callers, but in a trivial way.
The selftest also needs to be updated. I want to keep the test cases
as-is, where the expected pieces contain the expected string, and not
hard-code an expected index. To achieve this, add the
expected_format_piece structure. Note that the previous
format_piece::operator== didn't compare the n_int_args fields, while the
test provides expected values for that field. I guess that was a
mistake. The new code checks it, and the test still passes.
Change-Id: I80630ff60e01c8caaa800ae22f69a9a7660bc9e9 Reviewed-By: Keith Seitz <keiths@redhat.com>
Richard Earnshaw [Mon, 15 Sep 2025 10:42:52 +0000 (11:42 +0100)]
arm: Rename some tests to avoid duplicate tests names
A number of arm-specific tests print the same name. This can cause problems
if one of those tests fails, since then comparing tests with GCC's
compare_tests script can result in ambiguities in the changes summary.
Avoid this by giving tests unique names.
Still to do is where a test is run more than once (eg by having multiple
'#as: ' lines). This will require a tweak to the framework.
Andrew Burgess [Thu, 20 Jul 2023 10:12:40 +0000 (11:12 +0100)]
gdb: improve show text and help text for 'remote exec-file'
The current behaviour for 'show remote exec-file' is this:
(gdb) show remote exec-file
(gdb) set remote exec-file /abc
(gdb) show remote exec-file
/abc
(gdb)
The first output, the blank line, is just GDB showing the default
empty value.
This output is not really inline with GDB's more full sentence style
output, so in this commit I've updated things, the output is now:
(gdb) show remote exec-file
The remote exec-file is unset, the default remote executable will be used.
(gdb) set remote exec-file /abc
(gdb) show remote exec-file
The remote exec-file is "/abc".
(gdb)
Which I think is more helpful to the user.
I have also updated the help text for this setting. Previously we had
a set/show header line, but no body text, now we have:
(gdb) help show remote exec-file
Show the remote file name for starting inferiors.
This is the file name, on the remote target, used when starting an
inferior, for example with the \"run\", \"start\", or \"starti\"
commands. This setting is only useful when debugging a remote target,
otherwise, this setting is not used.
(gdb)
Which I think is more helpful.
Reviewed-By: Mark Wielaard <mark@klomp.org> Tested-By: Mark Wielaard <mark@klomp.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Thu, 20 Jul 2023 09:25:43 +0000 (10:25 +0100)]
gdb: improve how 'remote exec-file' is stored and accessed
This commit makes two related changes. The goal of the commit is to
update the 'remote exec-file' setting to work correctly in a
multi-inferior setup. To do this I have switched from the older
style add_setshow_* function, which uses a single backing variable, to
the newer style add_setshow_* functions that uses a get/set callback.
The get/set callbacks now directly access the state held in the
progspace which ensures that the correct value is always returned.
However, the new get/set API requires that the get callback return a
reference to the setting's value, which in this case needs to be a
std::string.
Currently the 'remote exec-file' setting is stored as a 'char *'
string, which isn't going to work.
And so, this commit also changes 'remote exec-file' to be stored as a
std::string within the progspace.
Now, when switching between multiple inferiors, GDB can correctly
inform the user about the value of the 'remote exec-file' setting.
Andrew Burgess [Thu, 20 Jul 2023 09:20:33 +0000 (10:20 +0100)]
gdb: have remote_target::extended_remote_run take the exec filename
Small refactor, have remote_target::extended_remote_run take the name
of the executable to run rather than looking it up directly, the one
caller of this function has already looked up the remote-exec
filename.
There should be no user visible changes after this commit.
Tom de Vries [Sat, 13 Sep 2025 10:36:33 +0000 (12:36 +0200)]
[gdb/testsuite] Fix test names in gdb.tui/{empty,new-layout}.exp
Post-commit review [1] pointed out that this change in gdb.tui/empty.exp:
...
- eval Term::check_box [list "box $boxno"] $box
+ Term::check_box [list "box $boxno"] {*}$box
...
is incomplete because it leaves the "[list ...]" in place.
Indeed, it changes the test name like this:
...
-PASS: gdb.tui/empty.exp: src: 80x24: box 1
+PASS: gdb.tui/empty.exp: src: 80x24: {box 1}
...
Add DRAFT marker to be emitted in the info, pdf and html outputs. This
is done in two places: one in the @ifnottex block meant for PDF output
and another in @titlepage block meant for info and html output.
While at it, also add date to non-pdf outputs.
The marker lines:
@center @strong{*** DRAFT - NOT FOR DISTRIBUTION ***}
should be removed before a release.
libsframe/doc/
* sframe-spec.texi: Add marker for DRAFT.
Older versions of ncurses (including the version that ships inside
macos, and Centos 7) do not include the A_ITALIC macro. This patch
simply hides any use of A_ITALIC behind a preprocessor guard.
The result of this is that italics won't be rendered in the tui
if ncurses isn't supported. We do have other options if we think
it's important - for instance we could show italics as bold if
italics aren't supported. From my understanding, that might be
overthinking it - so I took the simplest approach here, just to
fix the build.
Those versions also define tgetnum as:
int tgetnum(char *id);
so attempting to compile for c++ results in the error:
ISO C++ forbids converting a string constant to 'char*' [-Werror=write-strings]
This is just a dated API issue, so a const cast resolves the issue.
Tom Tromey [Fri, 12 Sep 2025 16:59:20 +0000 (10:59 -0600)]
Fix 32-bit failure in array_long_idx.exp
Testing on the AdaCore-internal equivalent to array_long_idx.exp
showed that it failed on 32-bit targets. This patch fixes the problem
by arranging to use types that aren't target-dependent.
Andrew Burgess [Wed, 16 Jul 2025 14:31:28 +0000 (15:31 +0100)]
gdb: clear proceed status before starting a new inferior
This patch fixes a bug when 'set schedule-multiple on' is in use and a
second inferior is started using the 'run' command (or 'start' or
'starti'). This bug was reported as PR gdb/28777.
The problem appears as the first inferior terminating with an
unexpected SIGTRAP. The bug can be reproduced like this:
The final 'run' can be replaced with 'start' or 'starti'. The output
is different in the 'starti' case, but the cause is the same. For the
'run' and 'start' cases the final output is:
Starting program: /tmp/spin
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
In the 'starti' case the output is:
Starting program: /tmp/spin
Thread 2.1 "spin" stopped.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
What's happening is that GDB is failing to clear the previous proceed
status from inferior 1 before starting inferior 2. Normally when
schedule-multiple is off, this isn't a problem as 'run' only starts
the new inferior, and the new inferior will have no previous proceed
status that needs clearing.
But when schedule-multiple is on, starting a new inferior, with 'run'
and friends, will actually start all inferiors, including those that
previous stopped at a breakpoint with a SIGTRAP signal.
By failing to clear out the proceed status for those threads, when GDB
restarts inferior 1 it arranges for the thread to receive the SIGTRAP,
which is delivered, and, as GDB isn't expecting a SIGTRAP, is allowed
to kill the process.
Fix this by calling clear_proceed_status from run_command_1.
projects / thirdparty / binutils-gdb.git / log
