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
After the commit:
commit e5e76451fa
Date: Fri Oct 22 07:19:29 2021 +0000
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>
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
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
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
...
---------------------
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.
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.)
v1 was here:
https://inbox.sourceware.org/gdb-patches/20250530183845.2179955-1-tromey@adacore.com/
In v2 I've rebased and fixed up various tests that either changed or
were added since v1.
Regression tested on x86-64 Fedora 41.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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.
When GDB is configured with --program-prefix, we see:
Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/gcorebg.exp ...
FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished
FAIL: gdb.base/gcorebg.exp: detached=detached: Core file generated by gcore
FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished
FAIL: gdb.base/gcorebg.exp: detached=standard: Core file generated by gcore
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
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:
commit 71f1ab80f1
CommitDate: Mon Mar 6 16:49:19 2023 +0100
[gdb/testsuite] Allow args in gdb_caching_proc
This change:
# 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:
- return [uplevel 2 $real_name]
+ return [uplevel 2 [list $real_name {*}$args]]
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
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.
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.
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.
2025-09-15 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
bfd:
* config.bfd <powerpc-*-solaris2*>: Remove.
gas:
* NEWS: Mention Solaris/PowerPC removal.
* configure.ac <ppc-*-solaris*>: Remove.
* configure: Regenerate.
* configure.in: Regenerate.
* configure.tgt <ppc-*-solaris*>: Remove.
* config/tc-ppc.c (ppc_solaris_comment_chars): Remove.
(ppc_eabi_comment_chars): Remove.
(SOLARIS_P): Remove.
(msolaris): Remove.
(md_parse_option): Remove "solaris", "no-solaris" hangling.
(md_show_usage): Likewise.
(md_begin): Remove msolaris handling.
* config/tc-ppc.h (ppc_comment_chars): Fix declaration.
* stabs.c (s_stab_generic) [TC_PPC && OBJ_ELF]: Remove 4-arg
.stabd support.
* doc/as.texi (Overview, Target PowerPC options): Remove
-msolaris, -mno-solaris.
* doc/c-ppc.texi (PowerPC-Opts): Remove -msolaris, -mno-solaris.
(PowerPC-Chars): Remove ! as line comment character.
ld:
* configure.tgt <powerpc*-*-solaris*>: Remove.
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:
commit 9704b8b4bc
gdb/testsuite: remove unneeded calls to get_compiler_info
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
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>
Remove the three remaining uses of alloca in gdbsupport.
I only built-tested the Windows-only portion in pathstuff.cc.
Change-Id: Ie588fa57f43de900d5f42e93a8875a7da462404b
Reviewed-By: Keith Seitz <keiths@redhat.com>
I think it makes the code slightly easier to understand.
Change-Id: I49056728e43fbf37c2af8f3904a543c10e987bba
Reviewed-By: Keith Seitz <keiths@redhat.com>
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.
This implements the sdtrig extension, version 1.0[1] and ssstrict
extension, version 1.0[2].
[1]https://github.com/riscv/riscv-debug-spec/blob/main/Sdtrig.adoc
[2]https://github.com/riscv/riscv-profiles/issues/173
bfd/ChangeLog:
* elfxx-riscv.c: Added sdtrig and ssstrict v1.0, and imply rules.
gas/ChangeLog:
* NEWS: Updated for sdtrig and ssstrict.
* testsuite/gas/riscv/imply.d: DItto.
* testsuite/gas/riscv/imply.s: Ditto.
* testsuite/gas/riscv/march-help.l: Ditto.
