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
Don't swap in nor match corrupt section header in linker input to avoid
linker crash later.
PR ld/33457
* elfcode.h (elf_swap_shdr_in): Changed to return bool. Return
false for corrupt section header in linker input.
(elf_object_p): Reject if elf_swap_shdr_in returns false.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
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.
Since clang 19 we see:
~~
clang: warning: argument unused during compilation: '-nostartfiles' [-Wunused-command-line-argument]^M
gdb compile failed, clang: warning: argument unused during compilation: '-nostartfiles' [-Wunused-command-line-argument]
UNTESTED: gdb.arch/amd64-init-x87-values.exp: failed to prepare
~~
Fix this by only passing '-nostartfiles' when linking.
Approved-By: Tom Tromey <tom@tromey.com>
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>
I noticed a bad test in dwarf2/read.c:anonymous_struct_prefix:
attr = dw2_linkage_name_attr (die, cu);
const char *attr_name = attr->as_string ();
if (attr == NULL || attr_name == NULL)
return NULL;
Here, if attr==NULL, this will crash before the test can be executed.
This patch fixes the problem by hoisting the test. I'm checking this
in as obvious.
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.
Tested on x86_64-linux.
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>
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:
o | output)
prefix=$OPTARG
;;
And verified that this works:
$ ./gcore --output=salut 51286
...
Saved corefile salut.51286
...
Change-Id: I025be574699d67b18ada9d73ce8f2aa0c87d5a0d
Reviewed-By: Sébastien Darche <sdarche@efficios.com>
Reviewed-By: Keith Seitz <keiths@redhat.com>
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
gdb -nw -nx -q -iex "set height 0" -iex "set width 0" \
-iex "set interactive-mode on" \
-iex "maint set console-translation-mode binary" \
-i=mi
... 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
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.
Recent Go toolchains are causing GDB to crash on a relatively recent
workaround for a GAS bug:
commit a833790a62
Date: Wed Nov 1 00:33:12 2023 +0100
[gdb/symtab] Work around gas PR28629
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.
Approved-By: Andrew Burgess <aburgess@redhat.com>
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
...
[1] commit 7f6c7a5bb3 ("[pre-commit] Add tclint hook")
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.
Approved-By: Andrew Burgess <aburgess@redhat.com>
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.
Approved-By: Andrew Burgess <aburgess@redhat.com>
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.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
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.
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.
PR ld/33427
Patches introduced in the GCC mainline:
commit 8cad8f94b450be9b73d07bdeef7fa1778d3f2b96
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri Sep 5 15:40:51 2025 -0700
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.
See: https://sourceware.org/pipermail/binutils/2025-September/144225.html
This fix uses more appropriate assertions.
These values are always known at construction time, so pass them to the
constructor.
Add constructors to some lm_info_* types when it's easy and it makes
things cleaner.
Change-Id: Ie2d751be276470c10c81792a93bf3ddafbcd4c33
Approved-By: Tom Tromey <tom@tromey.com>
While writing patch "gdb/solib: pass lm_info, original_name and name to
solib constructor", I fell into this trap:
sos.emplace_back (std::move (info), info->name, info->name);
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>
(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>
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>
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.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
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.
Running tclint on the test-cases in gdb.compile shows a few problems.
While we're at it, likewise in lib/compile-support.exp
Fix these.
Tested on x86_64-linux (Fedora 42).
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.
Consequently, the tclint pre-commit check passes:
...
$ pre-commit run --all-files -v tclint
tclint........................Passed
- hook id: tclint
- duration: 0.25s
$
...
PR testsuite/33403
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/nmoroze/tclint
[2] https://github.com/nmoroze/tclint/issues/110
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>
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
