icpx/icx give the following warning if '-g' is used without '-O'.
icpx: remark: Note that use of '-g' without any optimization-level
option will turn off most compiler optimizations similar to use of
'-O0'; use '-Rno-debug-disables-optimization' to disable this
remark [-Rdebug-disables-optimization]
The warning makes dejagnu think that compilation has failed. E.g.:
$ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
...
gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization]
=== gdb Summary ===
# of untested testcases 1
Furthermore, if no -O flag is passed, icx/icc optimize
the code by default. This breaks assumptions in many GDB tests
that the code is unoptimized by default. E.g.:
$ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
...
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const'
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile'
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile'
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator ==
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&)
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char)
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int)
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)"
FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple()
=== gdb Summary ===
# of expected passes 1
# of unexpected failures 9
To fix both problems, pass the -O0 flag explicitly, if no optimization
option is given.
With this patch we get, e.g.:
$ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
...
=== gdb Summary ===
# of expected passes 19
# of known failures 1
Approved-By: Tom Tromey <tom@tromey.com>
Starting with icc/icpc version 2021.7.0 and higher both compilers emit a
deprecation remark when used. E.g.
>> icc --version
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
deprecated and will be removed from product release in the second half
of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended
compiler moving forward. Please transition to use this compiler. Use
'-diag-disable=10441' to disable this message.
icc (ICC) 2021.7.0 20220713
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
>> icpc --version
icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
deprecated ...
icpc (ICC) 2021.7.0 20220720
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
As the testsuite compile fails when unexpected output by the compiler is
seen this change in the compiler breaks all existing icc and icpc tests.
This patch makes the gdb testsuite more forgiving by a) allowing the
output of the remark when trying to figure out the compiler version
and by b) adding '-diag-disable=10441' to the compile command whenever
gdb_compile is called without the intention to detect the compiler.
Approved-By: Tom Tromey <tom@tromey.com>
Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused,
amongst others:
(gdb) break 1^M
No line 1 in the current file.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1
FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set
This is because it removed one empty -re clause (matching just the
prompt) that is necessary after replying "n" to the pending breakpoint
question. Add this clause back.
Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6
Approved-By: Tom de Vries <tdevries@suse.de>
A refactoring in 4b9728bec1 (gdb: use gdb_test_multiple in
gdb_breakpoint) left the $test_name variable undefined.
This patch fixes this.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When running the testsuite in a non-optimized build on a slow machine, I
sometimes get:
UNTESTED: gdb.gdb/selftest.exp: Cannot set breakpoint at captured_main, skipping testcase.
do_self_tests, in lib/selftest-support.exp, uses `with_timeout_factor
10`, to account for the fact that reading the debug info of the gdb
binary (especially in a non-optimized GDB) can take time. But then it
ends up calling gdb_breakpoint, which uses gdb_expect with a hard-coded
timeout of 30 seconds.
Fix this by making gdb_breakpoint use gdb_test_multiple, which is a
desired change anyway for this kind of simple command / expected
output case.
Change-Id: I9b06ce991cc584810d8cc231b2b4893980b8be75
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
This adds a test case for "finish" with variably-sized types, and for
inferior calls as well. This also extends the "runto" proc to handle
temporary breakpoints.
On a x86_64-linux machine with pkru register, I run into:
...
(gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value
info register pkru^M
pkru 0x12345678 305419896^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value
...
This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU
onto ptrace()"). This is fixed by recent kernel commit 4a804c4f8356
("x86/fpu: Allow PKRU to be (once again) written by ptrace.").
The regression occurs for kernel versions v5.14-rc1 (the first tag containing
the regression) up to but excluding v6.2-rc1 (the first tag containing the fix).
Fix this by adding an xfail for the appropriate kernel versions.
Tested on x86_64-linux.
PR testsuite/29790
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790
The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
to communicate with debuggers. You can find more information here:
https://microsoft.github.io/debug-adapter-protocol/
Frequently this is implemented as a shim, but it seemed to me that GDB
could implement it directly, via the Python API. This patch is the
initial implementation.
DAP is implemented as a new "interp". This is slightly weird, because
it doesn't act like an ordinary interpreter -- for example it doesn't
implement a command syntax, and doesn't use GDB's ordinary event loop.
However, this seemed like the best approach overall.
To run GDB in this mode, use:
gdb -i=dap
The DAP code will accept JSON-RPC messages on stdin and print
responses to stdout. GDB redirects the inferior's stdout to a new
pipe so that output can be encapsulated by the protocol.
The Python code uses multiple threads to do its work. Separate
threads are used for reading JSON from the client and for writing JSON
to the client. All GDB work is done in the main thread. (The first
implementation used asyncio, but this had some limitations, and so I
rewrote it to use threads instead.)
This is not a complete implementation of the protocol, but it does
implement enough to demonstrate that the overall approach works.
There is a rudimentary test suite. It uses a JSON parser written in
pure Tcl. This parser is under the same license as Tcl itself, so I
felt it was acceptable to simply import it into the tree.
There is also a bit of documentation -- just documenting the new
interpreter name.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
MI version 1 is long since obsolete. Several years ago, I filed
PR mi/23170 for this. I think it's finally time to remove this.
Any users of MI 1 can and should upgrade to a newer version.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170
The following commit broke the readnow detection in the testsuite:
commit dfaa040b44
Date: Mon Mar 29 18:31:31 2021 -0600
Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
The testsuite checks if GDB was started with the -readnow flag by
using the 'maintenance print objfiles' command, and looking for the
string 'faked for "readnow"' in the output. This is implemented in
two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp).
The following tests all currently depend on this detection:
gdb.base/maint.exp
gdb.cp/nsalias.exp
gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp
gdb.dwarf2/dw2-stack-boundary.exp
gdb.dwarf2/dw2-zero-range.exp
gdb.dwarf2/gdb-index-nodebug.exp
gdb.mi/mi-info-sources.exp
gdb.python/py-symbol.exp
gdb.rust/traits.exp
The following test also includes detection of 'readnow', but does the
detection itself by checking $::GDBFLAGS for the readnow flag:
gdb.opt/break-on-_exit.exp
The above commit removed from GDB the code that produced the 'faked
for "readnow"' string, as a consequence the testsuite can no longer
correctly spot when readnow is in use, and many of the above tests
will fail (at least partially).
When looking at the above tests, I noticed that gdb.rust/traits.exp
does call `readnow`, but doesn't actually use the result, so I've
removed the readnow call, this simplifies the next part of this patch
as gdb.rust/traits.exp was the only place an extra regexp was passed
to the readnow call.
Next I have rewritten `readnow` to check the $GDBFLAGS for the
-readnow flag, and removed the `maintenance print objfiles` check. At
least for all the tests above, when using the readnow board, this is
good enough to get everything passing again.
For the `mi_readnow` proc, I changed this to just call `readnow` from
gdb.exp, I left the mi_readnow name in place - in the future it might
be the case that we want to do some different checks here.
Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow`
proc.
With these changes, all of the tests listed above now pass correctly
when using the readnow board.
When building GDB with the following CFLAGS and CXXFLAGS as part of
configure line:
CFLAGS=-std=gnu11 CXXFLAGS=-std=gnu++11
Then run the selftest.exp, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
FAIL: gdb.gdb/selftest.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
=== gdb Summary ===
# of unexpected failures 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
It is the fact that when I use the previously mentioned CFLAGS and
CXXFLAGS as part of the configuration line, the default value (-O2 -g)
is overridden, then GDB has no debug information. When there's no debug
information, GDB should not run the testcase in selftest.exp.
The root cause of this FAIL is that the $gdb_file_cmd_debug_info didn't
get the right value ("nodebug") during the gdb_file_cmd procedure.
That's because in this commit,
commit 3453e7e409
Date: Sat May 19 11:25:20 2018 -0600
Clean up "Reading symbols" output
It changed "no debugging..." to "No debugging..." which causes the above
problem. This patch only updates the corresponding pattern to fix this
issue.
With this patch applied, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
=== gdb Summary ===
# of untested testcases 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR compile/29541 points out that some of the C++ tests in gdb.compile
will time out when the glibc debuginfo is installed. This was
interfering with my hacking on gdb by making test runs extremely long,
so I looked into it.
Internally the bug seems to be that gdb tries to convert multiple
symbols named "var" via the compiler interface; one such symbol (I
didn't track it down too far) causes the C++ compiler plugin to crash.
Unfortunately, the crash is reported as a timeout, as the gdb side of
the plugin simply hangs. This seems like a bug in the plugin RPC
mechanism and, worse, apparently when I wrote this stuff I didn't
really consider error reporting very much at all, so gdb can't really
detect failures in the first place.
Anyway... this patch works around the timeout by compiling a simple
test that should provoke this bug, and then using "untested" if it
notices a GCC crash.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29541
skip_compile_feature_tests checks for "Command not supported on this
host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
gnulib module, fix mingw build"). This patch removes the obsolete
test.
I noticed that there are two identical copies of
skip_compile_feature_tests in the test suite. This removes one from
gdb.exp, in favor of the one in compile-support.exp.
When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
file system, I run into timeouts due to core generation, like for instance:
...
(gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
...
Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.
Tested on powerpc64le-linux.
Approved-By: Tom Tromey <tom@tromey.com>
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
gdb_unload crashed GDB, leaving no trace in the test results. Change it
to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I
think it is good practice anyway.
Make it return the result of gdb_test_multiple directly, change
gdb.python/py-objfile.exp accordingly.
Change gdb.base/endian.exp as well to avoid duplicate test names.
Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
since gdb_unload does it already now.
Change-Id: I59a1e4947691330797e6ce23277942547c437a48
Approved-By: Tom de Vries <tdevries@suse.de>
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
... the testsuite only outputs PASSes, and an ERROR, resulting from an
uncaught exception. This is a bit sneaky, because ERRORs are not
reported in the test summary. In certain circumstances, it can be easy
to miss.
Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes. But
this is only if it manages to send the command, and it's that command
that crashes GDB. Here, the ERROR is due to the fact that GDB had
already crashed by the time we entered gdb_test_multiple and tried to
send a command. GDB was crashed by the previous "file" command, sent by
gdb_unload. Because gdb_unload uses bare expect, it didn't record a
test failure when crashing GDB (this will be addressed separately).
In this patch, I propose to make gdb_test_multiple call unresolved
directly and return -1 send_gdb fails. This way, if GDB is already
crashed by the time we enter gdb_test_multiple, it will leave a trace in
the test results in the form of an UNRESOLVED. It will also spare us
the not-so-useful-in-my-opinion TCL backtrace.
Before, it looks like:
ERROR: Couldn't send python print(objfile.filename) to GDB.
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
And after:
Couldn't send python print(objfile.filename) to GDB.
UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded
Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba
Approved-By: Tom de Vries <tdevries@suse.de>
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the testsuite
library files (in boards/, config/, and lib/). Previous commits have
removed all uses of the 'then' keyword from the test script files,
this commit just cleans up the library files.
There should be no changes in what is tested after this commit.
When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I
noticed:
...
FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout)
...
The timeout is 10 seconds, but generating the core file takes more than a
minute, probably due to slow NFS.
I managed to reproduce this behaviour independently of gdb, by compiling
"int main (void) { __builtin_abort (); }" and running it, which took 1.5
seconds for a core file 50 times smaller than the one for gdb.
Fix this by preventing the core file from being generated, using a wrapper
around gdb that does "ulimit -c 0".
Tested on x86_64-linux.
ctxobj.exp fails randomly when computer is loaded.
With the addition of $gdb_prompt in the regexp testing for breakpoint hit,
I could not make it fail anymore.
Also fixed a typo in a comment.
This implements the request given in PR breakpoints/12464.
Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.
Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.
$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
disable $_hit_bpnum.$_hit_locno
In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.
This also fixes a strange behaviour: when a breakpoint X has only
one location,
enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.
The changes in RFA v4 handle the comments of Tom Tromey:
- Changed convenience var names from $bkptno/$locno to
$_hit_bpnum/$_hit_locno.
- updated the tests and user manual accordingly.
User manual also explictly describes that $_hit_locno is set to 1
for a breakpoint with a single location.
- The variable values are now set in bpstat_do_actions_1 so that
they are set for silent breakpoints, and when several breakpoints
are hit at the same time, that the variables are set to the printed
breakpoint.
The changes in RFA v3 handle the additional comments of Eli:
GDB/NEW:
- Use max 80-column
- Use 'code location' instead of 'location'.
- Fix typo $bkpno
- Ensure that disable $bkptno and disable $bkptno.$locno have
each their explanation inthe example
- Reworded the 'breakpoint-hit' paragraph.
gdb.texinfo:
- Use 'code location' instead of 'location'.
- Add a note to clarify the distinction between $bkptno and $bpnum.
- Use @kbd instead of examples with only one command.
Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
- Use %s for the result of paddress
- Use bkptno_numopt_re instead of 2 different -re cases
- use C@t{++}
- Add index entries for $bkptno and $locno
- Added an example for "locno" in the mi interface
- Added examples in the Break command manual.
I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was
failing when run with Clang as the compiler.
This test relies on the compiled binaries having a build-id within
them. For GCC, really GNU ld, the default is to always include a
build-id.
When compiling with Clang though, the default is for no build-id.
I did consider *always* turning on the build-id feature when the
compiler is Clang, but that felt a little weird.
Instead, I propose that we add a new 'build-id' compiler option to
gdb_compile, this flag indicates that the test _requires_ a build-id.
In gcc_compile we can then add the required flags if the compiler is
Clang so that we do get a build-id.
With this change the gdb.debuginfod/fetch_src_and_symbols.exp test
now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with
gcc. The 'mostly' part is an unrelated issue, and will be addressed
in a later commit in this series.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
I noticed in test-case gdb.arch/i386-biarch-core.exp that we run into the
completion limit for "complete set gnutarget":
...
set gnutarget vms-libtxt^M
set gnutarget *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.arch/i386-biarch-core.exp: complete set gnutarget
...
Fix this by using get_set_option_choices.
Also use get_set_option_choices for "complete set architecture i386", which
required extending get_set_option_choices to accept a second argument, such
that we can do:
...
set archs [get_set_option_choices "set architecture" "i386"]
...
because this returns an empty list:
...
set archs [get_set_option_choices "set architecture i386"]
...
because it does "complete set architecture i386 ".
Also clean up the explicit gdb_exit/gdb_start and use clean_restart instead.
Tested on x86_64-linux.
After de-installing bzip2, I run into:
...
Running ppc64-symtab-cordic.exp ...
sh: bzip2: command not found
PATH: gdb.arch/ppc64-symtab-cordic.exp: failed bzip2 for \
src/gdb/testsuite/gdb.arch/cordic.ko.bz2
...
Fix these by:
- using remote_exec instead of catch system, and
- using file tail in the untested message.
I've tried making output redirection work with remote_exec, but that seems to
be broken, so we now:
- copy the file $f.bz2 into the desired location $dir/$f.bz2, and
- decompress the bz2 file using "bzip2 -df $dir/$f.bz2", resulting in a file
$dir/$f.
Factor out new function decompress_bz2 to make the test-case less verbose, and
also use it in gdb.arch/i386-biarch-core.exp.
Tested on x86_64-linux, without and with bzip2 installed.
I get some random failures since commit 8d45c3a82a ("[gdb/testsuite]
Set completions to unlimited in get_set_option_choices"), which can be
reproduced with:
$ make check-read1 TESTS="gdb.base/parse_number.exp"
For instance:
set architecture A^M
Ambiguous item "A".^M
(gdb) FAIL: gdb.base/parse_number.exp: arch=A: set architecture A
The problem is the regexp in get_set_option_choices, it is possible that
is only matches part of a completion result. With check-read1, that is
always one letter.
Fix this by expecting the \r\n at the end of the line, so we only match
entire results. Use ^ in match patterns to ensure we don't miss any
output.
Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: Ib1733737feab7dde0f7095866e089081a891054e
When running test-case gdb.base/print-file-var.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by using the name of a shared lib as returned by gdb_load_shlib.
This required splitting up the gdb_load_shlib functionality, which is now
defined as:
...
proc gdb_load_shlib { file } {
set dest [gdb_download_shlib $file]
gdb_locate_shlib $file
return $dest
}
...
such that we can do gdb_download_shlib before gdb is started.
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
On aarch64-linux, with a gdb build without libexpat, so without xml support, I
run into:
...
(gdb) builtin_spawn attach-no-multi-process^M
attach 26808^M
Attaching to Remote target^M
warning: Can not parse XML target description; XML support was disabled at \
compile time^M
Reading symbols from attach-no-multi-process...^M
Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M
...
The test-case checks for skip_gdbserver_tests and that one contains a check
for xml support:
...
# If GDB is lack of XML support, and targets, like arm, have
# multiple target descriptions, GDB doesn't know which target
# description GDBserver uses, and may fail to parse 'g' packet
# after connection.
if { [gdb_skip_xml_test]
&& ([istarget "arm*-*-linux*"]
|| [istarget "mips*-*-linux*"]
|| [istarget "powerpc*-*-linux*"]
|| [istarget "s390*-*-linux*"]
|| [istarget "x86_64-*-linux*"]
|| [istarget "i\[34567\]86-*-linux*"]) } {
return 1
}
...
but it doesn't trigger because aarch64 is missing.
Fix this by adding istarget "aarch64*-*-linux*".
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Currently, a non-trivial return value from a function cannot currently be
reliably determined on PowerPC. This is due to the fact that the PowerPC
ABI uses register r3 to store the address of the buffer containing the
non-trivial return value when the function is called. The PowerPC ABI
does not guarantee the value in register r3 is not modified in the
function. Thus the value in r3 cannot be reliably used to obtain the
return addreses on exit from the function.
This patch adds a new gdbarch method to allow PowerPC to access the value
of r3 on entry to a function. On PowerPC, the new gdbarch method attempts
to use the DW_OP_entry_value for the DWARF entries, when exiting the
function, to determine the value of r3 on entry to the function. This
requires the use of the -fvar-tracking compiler option to compile the
user application thus generating the DW_OP_entry_value in the binary. The
DW_OP_entry_value entries in the binary file allows GDB to resolve the
DW_TAG_call_site entries. This new gdbarch method is used to get the
return buffer address, in the case of a function returning a nontrivial
data type, on exit from the function. The GDB function should_stop checks
to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to
zero by the new gdbarch method call for all architectures except PowerPC.
The get_return_value function will be used to obtain the return value on
all other architectures as is currently being done if RETURN_BUF is zero.
On PowerPC, the new gdbarch method will return a nonzero address in
RETURN_BUF if the value can be determined. The value_at function uses the
return buffer address to get the return value.
This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp.
The correct function return values are now reported.
Note this patch is dependent on patch: "PowerPC, function
ppc64_sysv_abi_return_value add missing return value convention".
This patch has been tested on Power 10 and x86-64 with no regressions.
I realized that the more irregular output of show arch:
...
(gdb) show arch^M
The target architecture is set to "auto" (currently "i386").^M
...
would be a problem for something like:
...
with_set arch powerpc:common64 {}
...
and indeed:
...
(gdb) set arch powerpc:common64^M
The target architecture is set to "powerpc:common64".^M
(gdb) FAIL: gdb.base/foo.exp: set arch powerpc:common64
...
and:
...
(gdb) set arch set to "auto" (currently "i386")^M
Undefined item: "set".^M
...
Fix this in with_set by handling this type of output.
Tested on x86_64-linux.
In some test-case I tried to use get_set_option_choices "set architecture" and
ran into max-completions:
...
set architecture simple^M
set architecture tomcat^M
set architecture xscale^M
set architecture *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.base/foo.exp: complete set architecture
...
There's only one test-case using this currently: gdb.base/parse_number.exp,
and it locally sets max-completions to unlimited.
Fix this by:
- factoring out a new proc with_set out of proc with_complaints, and
- using it to temporarily set max-completions to unlimited in
get_set_option_choice.
Tested on x86_64-linux, by running test-cases that excercise
get_set_option_choice and with_complaints.
We're currently running into a timeout at:
...
(gdb) start ^M
Error in expression, near `1'.^M
(gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right \
procedure
...
due to the fact that gdb_start_cmd doesn't handle a prompt as reaction to
the start command.
Fix this by handling the prompt. Reduces execution time of the test-case from
1m1s to 1s.
Tested on x86_64-linux.
With gdb 12.1, on powerpc64le I ran into ERRORs related to has_hw_wp_support
usage, which was already fixed on trunk by commits:
- 13f7237241 ("gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc"), and
- 01a32ee0b8 ("PowerPC, fix gdb.base/watchpoint.exp on Power 9")
While looking into these ERRORs and the commits that fix them, it occurred to
me that while the commits fix the root cause, the failure mode is not great.
The test-cases expect a running instance of gdb upon return, which is not
there, so there's an long stream of ERRORs generated as a result.
Fix this at the start of has_hw_wp_support, by (instead of accomodating a
running gdb instance by calling gdb_exit), checking whether it's called
without a running gdb instance, and erroring out otherwise. This way, there's
just one error.
I also noticed that in case we do an early exit due to !runto_main, we don't
clean up, so copy the missing cleanups (gdb_exit and $obj file deletion) from
the regular exit.
Tested on x86_64-linux, using has_hw_wp_support for x86_64 in
skip_hw_watchpoint_tests.
When calling get_func_info inside a test case, it would cause failures
if the function was printed using a C++ style mangled name. The current
patch fixes this by allowing for mangled names along with the current
rules.
Approved-By: Tom Tromey <tom@tromey.com>
With test-case gdb.base/bigcore.exp I run into:
...
(gdb) PASS: gdb.base/bigcore.exp: get inferior pid
signal SIGABRT^M
Continuing with signal SIGABRT.^M
^M
Program terminated with signal SIGABRT, Aborted.^M
The program no longer exists.^M
(gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
UNTESTED: gdb.base/bigcore.exp: can't generate a core file
...
due to find_core_file returning "".
There is a core file name core:
...
$ ls ./outputs/gdb.base/bigcore
bigcore bigcore.corefile core gdb.cmd.1 gdb.in.1 gdbserver.cmd.1
...
but it's not found.
The problem is this statement:
...
lappend files [list ${::testfile}.core core]
...
which adds a single list item "${::testfile}.core core".
Fix this in the most readable way:
...
lappend files ${::testfile}.core
lappend files core
...
Tested on x86_64-linux.
I noticed that running test-case gdb.mi/mi-exec-run.exp with host board
local-remote-host.exp takes about 44 seconds.
I found two silent timeouts responsible for this.
The first is in mi_gdb_exit, where we have:
...
if { [is_remote host] && [board_info host exists fileid] } {
send_gdb "999-gdb-exit\n"
gdb_expect 10 {
-re "y or n" {
send_gdb "y\n"
exp_continue
}
-re "Undefined command.*$gdb_prompt $" {
send_gdb "quit\n"
exp_continue
}
-re "DOSEXIT code" { }
}
}
...
so in gdb.log we see:
...
999-gdb-exit^M
999^exit^M
=thread-exited,id="1",group-id="i1"^M
=thread-group-exited,id="i1"^M
...
after which expect just waits for the timeout.
Fix this by adding a gdb_expect clause to parse the exit:
...
-re "\r\n999\\^exit\r\n" { }
...
Note that we're not parsing the thread-exited/thread-group-exited messages, because
they may not be present:
...
$ gdb -i=mi
=thread-group-added,id="i1"
(gdb)
999-gdb-exit
999^exit
$
...
After fixing that, we have:
...
(gdb) ^M
saw mi error
PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \
force-fail=1: run failure detected
quit^M
&"quit\n"^M
...
What seems to be happening is that default_gdb_exit sends a cli interpreter
quit command to an mi interpreter, after which again expect just waits for the
timeout.
Fix this by adding mi_gdb_exit to the end of the test-case, as in many other
gdb.mi/*.exp test-cases.
After these two fixes, the test-case takes about 4 seconds.
Tested on x86_64-linux.
On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and
some hardcoded assembly test-cases:
...
Running gdb.dwarf2/fission-absolute-dwo.exp ...
gdb compile failed, ld: warning: fission-absolute-dwo.o: \
missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future \
version of the linker
=== gdb Summary ===
# of untested testcases 1
...
Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in
proc Dwarf::assemble.
Fix the hard-coded test-cases using this command:
...
$ for f in $(find gdb/testsuite/gdb.* -name *.S); do
if ! grep -q note.GNU-stack $f; then
echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f;
fi;
done
...
Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S.
The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08b
("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so
hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead.
Note that dwarf assembly testcases use %progbits as decided by proc _section.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29674
With test-case gdb.mi/mi-disassemble.exp and check-read1 I run into:
...
FAIL: gdb.mi/mi-disassemble.exp: disassemble /b main
FAIL: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x400549)"
...
The problem for both FAILs is that the output is parsed using
gdb_test_multiple, which has implicit clauses using $gdb_prompt, which can
match before the explicit clauses using $mi_gdb_prompt.
Fix this by passing -prompt "$mi_gdb_prompt$" to gdb_test_multiple.
Tested on x86-64-linux.
I spotted that the gdb.gdb/unittest.exp script causes a temporary file
inserters_extractors-2.txt to be created in build/gdb/testsuite/
instead of in build/gdb/testsuite/output/gdb.gdb/unittest/.
This is because some of the 'maint selftest' tests create temporary
files in GDB's current directory, specifically, the two source files:
gdb/unittests/basic_string_view/inserters/wchar_t/2.cc
gdb/unittests/basic_string_view/inserters/char/2.cc
both create a temporary file called inserters_extractors-2.txt, though
we only run the second of these as part of GDB's selftests.
I initially proposed just using GDB's 'cd' command in unittest.exp to
switch to the test output directory before running the selftests,
however, Pedro pointed out that there was a risk here that, if GDB
crashed during shutdown, the generated core file would be left in the
test output directory rather than in the testsuite directory. As a
result, our clever core file spotting logic would fail to spot the
core file and alert the user.
Instead, I propose this slightly more involved solution. I've added a
new with_gdb_cwd directory proc, used like this:
with_gdb_cwd $directory {
# Tests here...
}
The new proc temporarily switches to $directory and then runs the
tests within the block. After running the tests the previous current
working directory is restored.
Additionally, after switching back to the previous cwd, we check that
GDB is still responsive. This means that if GDB crashed immediately
prior to restoring the previous directory, and left the core file in
the wrong place, then the responsiveness check will fail, and a FAIL
will be emitted, this should be enough to alert the user that
something has gone wrong.
With this commit in place the unittest.exp script now leaves its
temporary file in the test output directory.
In glibc, the r_debug structure contains (amongst others) the following
fields:
int r_version:
Version number for this protocol. It should be greater than 0.
If r_version is 2, struct r_debug is extended to struct r_debug_extended
with one additional field:
struct r_debug_extended *r_next;
Link to the next r_debug_extended structure. Each r_debug_extended
structure represents a different namespace. The first r_debug_extended
structure is for the default namespace.
1. Change solib_svr4_r_map argument to take the debug base.
2. Add solib_svr4_r_next to find the link map in the next namespace from
the r_next field.
3. Update svr4_current_sos_direct to get the link map in the next namespace
from the r_next field.
4. Don't check shared libraries in other namespaces when updating shared
libraries in a new namespace.
5. Update svr4_same to check the load offset in addition to the name
6. Update svr4_default_sos to also set l_addr_inferior
7. Change the flat solib_list into a per-namespace list using the
namespace's r_debug address to identify the namespace.
Add gdb.base/dlmopen.exp to test this.
To remain backwards compatible with older gdbserver, we reserve the
namespace zero for a flat list of solibs from all namespaces. Subsequent
patches will extend RSP to allow listing libraries grouped by namespace.
This fixes PR 11839.
Co-authored-by: Lu, Hongjiu <hongjiu.lu@intel.com>
Check for
warning: Corrupted shared library list
and for
Invalid cast.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
in gdb_test_multiple.
With the test-case included in this patch, we run into:
...
(gdb) target remote localhost:2347^M
`target:twice-connect' has disappeared; keeping its symbols.^M
Remote debugging using localhost:2347^M
warning: Unable to find dynamic linker breakpoint function.^M
GDB will be unable to debug shared library initializers^M
and track explicitly loaded dynamic code.^M
Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M
0x00007ffff7dd4550 in ?? ()^M
(gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started
FAIL: gdb.server/twice-connect.exp: found interpreter
...
The problem originates in find_program_interpreter, where
bfd_get_section_contents is called to read .interp, but fails. The function
returns false but the result is ignored, so find_program_interpreter returns
some random string.
Fix this by checking the result of the call to bfd_get_section_contents.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652
Compilers default to either PIE or no-PIE executables.
In order to test PIE executables with a compiler that produces non-PIE by
default, we can use target board unix/-fPIE/-pie, which set the multilib_flags
of the target board to "-fPIE -pie".
Likewise, we can use target board unix/-fno-PIE/-no-pie with a compiler that
produces PIE by default.
The target board unix/-fno-PIE/-no-pie has a potential problem when compiling
shared libs, because the multilib_flags will override the attempts of
gdb_compile_shlib to compile with -fPIC. This is taken care of by running the
body of gdb_compile_shlib wrapped in with_PIE_multilib_flags_filtered.
The target board unix/-fPIE/-pie has a problem with nopie compilations. The
current approach is to do the compilation hoping for the best, and if we find
out that the resulting executable is PIE despite specifying nopie, we error
out with the standard error message "nopie failed to prevent PIE executable".
That however does not work for hard-coded assembly nopie test-cases, which will
just noisily refuse to compile:
...
ld: amd64-disp-step0.o: relocation R_X86_64_32S against `.text' can not be \
used when making a PIE object; recompile with -fPIE^M
...
Fix this in gdb_compile by filtering out the PIE settings in the target board
multilib_flags when pie or nopie is specified.
Tested on x86_64-linux.
Add a new proc cond_wrap, that can be used to replace the repetitive:
...
if { $cond } {
wrap {
<body>
}
} else {
<body>
}
...
with the shorter:
...
cond_wrap $cond wrap {
<body>
}
...
Tested on x86_64-linux.
With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I
run into:
...
as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \
unsupported relocation type: 0x1^M
...
The problem is that we have 64-bit dwarf so the debug_line offset in the
.debug_macro section is an 8-byte entity, emitted using ".8byte":
...
.section .debug_macro
.Lcu_macros4:
.2byte 5 /* version */
.byte 3 /* flags */
.8byte .LLlines3 /* debug_line offset */
...
but the linker doesn't support 8-byte relocation types on a 32-bit architecture.
This is similar to what was fixed in commit a5ac8e7fa3
("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance
.debug_abbrev.
Fix this in the same way, by using _op_offset to emit the debug_line offset.
Tested on x86_64-linux with native and target board unix/-m32.
I noticed in capture_command_output that the output of a single command is
matched using two gdb_test_multiples:
- the first one matching the echoed command and skipping an optional prefix,
- the second one matching the output and the prompt.
This is error-prone, because the first gdb_test_multiple has implicit
clauses which may consume the prompt.
The problem is easy to spot with an example. First consider:
...
set output [capture_command_output "print 1" "\\\$1 = "]
gdb_assert { [string equal $output "1"] }
...
for which we get:
...
PASS: [string equal $output "1"]
...
If we change the prefix string to a no-match, say "1 = ", and update the
output string match accordingly, we get instead:
...
FAIL: capture_command_output for print 1
FAIL: [string equal $output "\$1 = 1"]
...
The first FAIL is produced by the first gdb_test_multiple, consuming the prompt.
The second gdb_test_multiple then silently times out waiting for another prompt,
after which the second FAIL is produced. Note that the timeout is silent
because the gdb_test_multiple is called with an empty message argument.
The second FAIL is because capture_command_output returns "", given that all
the command output was consumed by the first gdb_test_multiple.
Fix this by rewriting capture_command_output to use only a single
gdb_test_multiple.
Tested on x86_64-linux.
I see some random failures in this test:
FAIL: gdb.base/async-shell.exp: run & (timeout)
It can be reliably reproduced on a recent enough GNU/Linux with this
change:
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 44cc28b30051..2a3c8253ba5a 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -1301,6 +1301,7 @@ proc gdb_test_multiple { command message args } {
}
set gdb_test_name "$message"
+ sleep 2
set result 0
set code [catch {gdb_expect $code} string]
"recent enough" means a system where libpthread.so was merged with
libc.so, so at least glibc 2.34.
The problem is that the `run &` command prints some things after the
prompt:
(gdb) [Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
If expect is quick enough, it will consume only up to the prompt. But
if it is slow enough, it will consume those messages at the same time as
the prompt, in which case the gdb_test used for "run &" won't match. By
default, the prompt used by gdb_test uses a `$` to anchor the match at
the end of the buffer. If there's anything following the prompt, it
won't match.
The diff above adds a delay between sending the command and consuming
the output, giving GDB more time to output the messages, giving a good
chance that expect consumes them at the same time as the prompt.
This is normally handled by using gdb_test_multiple and specifying a
pattern that ends with "$gdb_prompt", but not a trailing $. I think
this is common enough that it deserves its own gdb_test option.
Therefore, add the -no-anchor-prompt option to gdb_test, and
gdb_test_no_output for completeness. Use it in
gdb.base/async-shell.exp.
Change-Id: I9051d8800d1c10a2e95db1a575991f7723492f1b
Approved-By: Tom de Vries <tdevries@suse.de>
