| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A TCL proc will return the return value of the last command executed
within the proc's body if there is no explicit return call, so
gdb_test_no_output is already returning the return value of
gdb_test_multiple.
However, I'm not a fan of (relying on) this implicit return value
behaviour -- I prefer to be explicit about what we are doing. So in
this commit I have extended the comment on gdb_test_no_output to
document the possible return values (just as gdb_test does), and
explicitly call return.
This should make no different to our testing, but I think it's clearer
now what the gdb_test_no_output proc is expected to do.
The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the
return value of gdb_test_no_output, and continue to pass after this
change.
I also spotted that gdb.base/watchpoint.exp could be updated to make
use of gdb_test_no_output, so I did that.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
In test-case gdb.tui/empty.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/empty.exp: src: 90x40: box 1
...
We timeout here in Term::resize:
...
# Due to the strange column resizing behavior, and because we
# don't care about this intermediate resize, we don't check
# the size here.
wait_for "@@ resize done $_resize_count"
...
because the string we're trying to match is split over two lines:
...
25 -----------------------------------------------------------------------------+No
26 ne No process In: L?? PC: ?? @@
27 resize done 0, size = 79x40
28 (gdb)
...
Fix this by dropping the "@@ " prefix.
Tested on x86_64-linux.
|
|
In test-case gdb.tui/new-layout.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/new-layout.exp: layout=cmd_only {cmd 1} {} {}: \
bottom of cmd window is blank
...
The timeout happens here:
...
Term::command "layout src"
...
Before the "layout src" command we have:
...
Screen Dump (size 80 columns x 24 rows, cursor at column 46, row 7):
0 +-tui-layout.c-------------------------+(gdb) layout example3
1 | 20 { |(gdb) layout src
2 | 21 return 0; |(gdb) winheight cmd 8
3 | 22 } |(gdb) layout example4
4 | 23 |(gdb) layout src
5 | 24 |(gdb) winheight cmd 8
6 | 25 |(gdb) layout example5
7 | 26 |(gdb)
8 | 27 |
9 | 28 |
10 | 29 |
11 | 30 |
12 | 31 |
13 | 32 |
14 | 33 |
15 | 34 |
16 | 35 |
17 | 36 |
18 | 37 |
19 | 38 |
20 | 39 |
21 | 40 |
22 +--------------------------------------+
23 exec No process In: L?? PC: ??
...
and after:
...
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 16):
0 +-tui-layout.c-----------------------------------------------------------------+
1 | 20 { |
2 | 21 return 0; |
3 | 22 } |
4 | 23 |
5 | 24 |
6 | 25 |
7 | 26 |
8 | 27 |
9 | 28 |
10 | 29 |
11 | 30 |
12 | 31 |
13 | 32 |
14 +------------------------------------------------------------------------------+
15 exec No process In: L?? PC: ??
16 (gdb)
17
18
19
20
21
22
23
...
The Term::command "layout src" is waiting to match:
- "(gdb) layout src", and then
- "(gdb) ".
The first part fails to match on a line:
...
| 26 |(gdb) layout src
...
because it expects the prompt at the start of the line.
Fix this by allowing the prompt at the start of a window as well.
Tested by x86_64-linux.
|
|
The semantics of wait_for are non-trivial, and a bit hard to understand
sometimes.
Add some debug prints in wait_for that make it clear:
- what regexps we're trying to match,
- what strings we compare to the regexps, and
- whether there's a match or mismatch.
I've added this ad-hoc a couple of times, and it seems that it's worth having
readily available.
The debug prints are enabled by adding DEBUG_TUI_MATCHING=1 to the
RUNTESTFLAGS:
...
$ make check RUNTESTFLAGS="gdb.tui/empty.exp DEBUG_TUI_MATCHING=1"
...
Tested on x86_64-linux.
|
|
In accept_gdb_output we have:
...
timeout {
# Assume a timeout means we somehow missed the
# expected result, and carry on.
return 0
}
...
The timeout is silent, and though in some places the return value is checked,
this is not done consistently, and consequently there are silent timeouts
when running the TUI testsuite (gdb.tui/*.exp and gdb.python/tui*.exp).
Each timeout is 10 seconds, and there are 5 in total in the TUI tests, taking
50 seconds overall:
...
real 1m0.275s
user 0m10.440s
sys 0m1.343s
...
With an entire testsuite run taking about 30 minutes, that is about 2.5% of
the time spent waiting in TUI tests.
Let's make the timeouts visible using a warning, such that they can be fixed.
Tested on x86_64-linux.
|
|
While writing a gdb_test_multiple call in a test-case I tried to use -wrap in
combination with -prompt and found out that it doesn't work, because -wrap uses
"$gdb_prompt $" instead of $prompt_regexp.
Fix this by making -wrap use $prompt_regexp.
Tested on x86_64-linux.
|
|
When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into:
...
Running gdb/testsuite/gdb.multi/multi-arch.exp ...
gdb compile failed, In file included from /usr/include/features.h:399:0,
from /usr/include/stdio.h:27,
from gdb/testsuite/gdb.multi/hangout.c:18:
/usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \
No such file or directory
# include <gnu/stubs-32.h>
^
compilation terminated.
...
The problem is that the test-case attempts to use gcc -m32 to produce an
executable while that's not available.
Fix this by:
- introduce a new caching proc have_compile_and_link_flag, and
- using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp.
Tested on:
- x86_64-linux (openSUSE Leap 15.4), and
- powerpc64le-linux (CentOS-7).
|
|
With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp.
ERROR: invalid command name "lmap"
while executing
"::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \
dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }"
...
Fix this by adding basic lmap support for tcl version < 8.6.
Tested on x86_64-linux.
|
|
When running the dap tests on a system with tcl 8.5, we run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp.
ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \
digit, double, false, graph, integer, list, lower, print, punct, space, \
true, upper, wideinteger, wordchar, or xdigit
while executing
"string is entier $num"
(procedure "num" line 16)
invoked from within
...
Fix this by:
- requiring tcl 8.6 in allow_dap_tests, and
- adding the missing require allow_dap_tests in gdb.dap/memory.exp.
Tested on x86_64-linux.
|
|
When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used
rather than dejagnu's copy (mimicing what happens with an older dejagnu
without find_gdc), I run into these debug prints:
...
Tool Root: /data/vries/gdb/leap-15-4/build
CC: gdc
...
Remove these.
Tested on x86_64-linux.
|
|
This commit changes mi_make_breakpoint_pending to accept the 'script'
and 'times' arguments.
I've then added a new test that makes use of 'scripts' in
gdb.mi/mi-pending.exp and gdb.mi/mi-dprintf-pending.exp.
There is already a test in gdb.mi/mi-pending.exp that uses the 'times'
argument -- previously this argument was being ignored, but is now
used.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Commit:
commit c569a946f6925d3f210c3eaf74dcda56843350ef
Date: Fri Mar 24 10:45:37 2023 +0100
[gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument
Introduced the use of {"} in mi-support.exp. There is absolutely
nothing wrong with this in any way. However, this is causing my
editor to get the syntax highlighting of this file wrong after this
point.
Maybe the real answer is to use a better editor, or fix my current
editor.... but I'm hoping I can instead take the lazy approach of just
changing {"} to "\"", which is handled fine, and means exactly the
same as far as I understand it.
There should be no change in what is tested after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Spotted a small typo in gdb_breakpoint proc, we use $gdb_name_name
instead of $gdb_test_name in one place. Fixed in this commit.
|
|
Whenever we start gdb in the testsuite, we have the rather verbose:
...
$ gdb
GNU gdb (GDB) 14.0.50.20230405-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)
...
This makes gdb.log longer than necessary and harder to read.
We do need to test that the output is produced, but that should be limited to
one or a few test-cases.
Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have:
...
$ gdb -q
(gdb)
...
Tested on x86_64-linux.
|
|
With test-case gdb.threads/threadapply.exp and editing set to on, we have:
...
(gdb) define remove^M
Type commands for definition of "remove".^M
End with a line saying just "end".^M
>remove-inferiors 3^M
>end^M
(gdb)
...
but with editing set to off, we run into:
...
(gdb) define remove^M
Type commands for definition of "remove".^M
End with a line saying just "end".^M
>remove-inferiors 3^M
end^M
>(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \
define remove (timeout)
...
The commands are issued by this test:
...
gdb_define_cmd "remove" {
"remove-inferiors 3"
}
...
which does:
- gdb_test_multiple "define remove", followed by
- gdb_test_multiple "remove-inferiors 3\nend".
Proc gdb_test_multiple has special handling for multi-line commands, which
splits it up into subcommands, and for each subcommand issues it and then
waits for the resulting prompt (the secondary prompt ">" for all but the last
subcommand).
However, that doesn't work as expected in this case because the initial
gdb_test_multiple "define remove" fails to match all resulting output, and
consequently the secondary prompt resulting from "define remove" is counted as
if it was the one resulting from "remove-inferiors 3".
Fix this by matching the entire output of "define remove", including the
secondary prompt.
Tested on x86_64-linux.
PR testsuite/30288
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
|
|
version_at_least is a less capable variant of version_compare, so this
patch removes it.
|
|
This rewrites version_compare to allow the input lists to have
different lengths, then rewrites rust_at_least to use version_compare.
|
|
This adds a 'rust_at_least' helper proc, for checking the version of
the Rust compiler in use. It then changes various tests to use this
with 'require'.
|
|
PR mi/11335 points out that an MI varobj will not display the result
of a pretty-printer's "to_string" method. Instead, it always shows
"{...}".
This does not seem very useful, and there have been multiple
complaints about it over the years. This patch changes varobj to emit
this string when possible, and updates the test suite.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
|
|
When an allow_* proc returns false, it can be a bit difficult what check
failed exactly, if the procedure does multiple checks. To make
investigation easier, I propose to allow the "require" callbacks to be
able to return a list of two elements: the zero/non-zero value, and a
reason string.
Use the new feature in allow_hipcc_tests to demonstrate it (it's also
where I hit actually hit this inconvenience). On my computer (where GDB
is built with amd-dbgapi support but where I don't have a suitable GPU
target), I get:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found)
vs before:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests
Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives
the wrong answer for gdb.rust/expr.exp, which doesn't require it.
Fix this by using can_compile rust in the test-cases that need it, and just
returning 1 in allow_rust_tests.
Tested on x86_64-linux.
|
|
If I deinstall the rust compiler, I get:
...
gdb compile failed, default_target_compile: Can't find rustc --color never.
UNTESTED: gdb.rust/watch.exp: failed to prepare
...
Fix this by adding can_compile rust, and using it in allow_rust_tests, such
that we have instead:
...
UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests
...
Since the rest of the code in allow_rust_tests is also about availability of
the rust compiler, move it to can_compile.
Tested on x86_64-linux.
|
|
With test-case gdb.rust/watch.exp and remote host I run into:
...
Executing on host: gcc watch.rs -g -lm -o watch (timeout = 300)
...
ld:watch.rs: file format not recognized; treating as linker script
ld:watch.rs:1: syntax error
...
UNTESTED: gdb.rust/watch.exp: failed to prepare
...
The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails.
Fix this by returning 0 in allow_rust_tests for remote host.
Tested on x86_64-linux.
|
|
Fix gnat_runtime_has_debug_info for remote host by checking for
allow_ada_tests.
This fixes an error for test-case gdb.testsuite/gdb-caching-proc.exp and
remote host.
Tested on x86_64-linux.
|
|
In do_self_tests we try to find out the location of the gdb to debug, which
will then be copied and renamed to xgdb.
In principle, the host board specifies the location of GDB, on host.
With remote host, we could upload that gdb from host to build/target, but we
would miss the data directory (which is listed as the reason to skip
do_self_tests for remote target).
We could fix that by instead taking the gdb from build instead, but that
wouldn't work with installed testing.
It seems easier to just skip this on remote host.
It could be made to work for the "[is_remote host] && [is_remote target]
&& host == target" scenario (see board local-remote-host-native.exp), but
that doesn't seem worth the effort.
Tested on x86_64-linux.
|
|
Fix test-case gdb.dwarf2/gdb-index-cxx.exp for remote host using
host_standard_output_file.
Tested on x86_64-linux.
|
|
Fix test-case gdb.dwarf2/gdb-index.exp on remote host using
gdb_remote_download and host_standard_output_file.
Also declare the test-case unsupported with readnow.
Tested on x86_64-linux.
|
|
A few test-cases in gdb.dwarf2 use something like:
...
additional_flags=\"-DFOO=BAR + 10\"
...
which doesn't work on remote host.
Fix this by introducing a new proc quote_for_host that also works for remote
host, such that we have:
...
additional_flags=[quote_for_host -DFOO=BAR + 10]
...
Tested on x86_64-linux.
|
|
Proc have_index is mostly used with $binfile, which gives problems
for remote host.
Fix this by using "file tail" on the proc argument.
Tested on x86_64-linux.
|
|
On openSUSE Leap 15.4, I get:
...
Running gdb.dlang/dlang-start.exp ...
gdb compile failed, default_target_compile: Can't find gdc.
UNTESTED: gdb.dlang/dlang-start.exp: failed to prepare
...
Fix this by:
- introducing a new proc can_compile, and
- requiring "can_compile d" in the test-case,
such that I have instead:
...
Running gdb.dlang/dlang-start.exp ...
UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d
...
Tested on x86_64-linux, on openSUSE Leap 15.4 and Fedora 37.
|
|
While trying to use gdb_can_simple_compile with a d program, I ran into:
...
/data/vries/gdb/f37/build/gdb/testsuite/temp/105856/can_compile_d-105856.d: \
error: module 'can_compile_d-105856' has non-identifier characters in \
filename, use module declaration instead
...
The d compiler has a problem with the filename can_compile_d-105856.d, which
contains the pid. The pid is added by gdb_simple_compile:
...
set obj [standard_temp_file $name-[pid].$postfix]
...
but it's unnecessary because standard_temp_file already uses the pid.
Fix this by removing "[pid]" in all calls to standard_temp_file.
Tested on x86_64-linux.
|
|
Simon pointed out that with gdb.dap/*.exp and target board
native-gdbserver, we run into problems.
I see for each test-case:
...
+++ run
Traceback (most recent call last):
File "startup.py", line 146, in exec_and_log
output = gdb.execute(cmd, from_tty=True, to_string=True)
gdb.error: Don't know how to run. Try "help target".
...
Likewise with target board native-extended-gdbserver.
Fix this by:
- adding a new proc allow_dap_tests,
- using it in all the gdb.dap tests, and
- bailing out if GDBFLAGS/INTERNAL_GDBFLAGS contains
"set auto-connect-native-target off".
Tested on x86_64-linux.
Reported-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In proc mi_expect_stop there's a proc argument reason that's handled like so:
...
set r "reason=\"$reason\","
...
That's fine for say:
...
set reason "foo"
...
for which this evaluates to:
...
set r "reason=\"foo\","
...
But there are more complex uses, for instance:
...
set reason "breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal"
...
which evaluates to:
...
set r "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...
Note how in this reason argument, the first two '\"' seems to form a pair
surrounding ',disp=', which is not the case, which is confusing.
Fix this by only adding the quotes in mi_expect_stop if the string doesn't
already contain quotes, such that we have the more readable:
...
set reason "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...
Tested on x86_64-linux.
|
|
Simon reported that doing:
...
$ while make check-parallel TESTS='gdb.opencl/*.exp' -j 100; do true; done
...
could run into:
...
ERROR: remote_download to target of \
/data/vries/gdb/src/gdb/testsuite/lib/opencl_kernel.cl to opencl_kernel.cl: \
cp: cannot create regular file 'opencl_kernel.cl': File exists
...
Fix this by using gdb_remote_download (instead of plain remote_download) in
allow_opencl_test, which takes care of:
- downloading to a location which is safe for parallel testing, by
using standard_output_file, and
- cleaning up the downloaded file, meaning we can remove the corresponding
"remote_file target delete ${clprogram}" lines in allow_opencl_test.
Tested on x86_64-linux.
Reported-by: Simon Marchi <simon.marchi@efficios.com>
|
|
Fix a few test-cases in gdb.cp/*.exp for remote host using new proc
include_file.
Tested on x86_64-linux.
|
|
Commit 1acc9dca423f ("Change linetables to be objfile-independent")
changed "maintenance info line-table" to print unrelocated addresses
instead of relocated. This breaks a few tests on systems where that
matters. The ones I see are:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ...
FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix)
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ...
FAIL: gdb.base/async.exp: stepi&
FAIL: gdb.base/async.exp: nexti&
FAIL: gdb.base/async.exp: finish&
These tests run "maintenance info line-table" to record the address of
some lines, and then use these addresses in expected patterns. It
therefore expects these addresses to match the runtime addresses,
therefore the relocated addresses.
Add back the relocated addresses, next to the unrelocated addresses,
like so:
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END
0 6 0x0000555555555119 0x0000000000001119 Y
1 7 0x000055555555511d 0x000000000000111d Y
2 8 0x0000555555555123 0x0000000000001123 Y
3 END 0x0000555555555125 0x0000000000001125 Y
The unrelocated addresses can always be useful trying to map this
information with a DWARF info dump.
Adjust the is_stmt_addresses proc in the testsuite to match the new
output.
Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf
|
|
Fix test-case gdb.xml/tdesc-reload.exp for remote host by using appropriate
filenames.
Tested on x86_64-linux.
|
|
Dejagnu's remotedir implementation has support in remote_exec and
remote_download, but not remote_upload.
Consider the following scenario:
- downloading an executable to target,
- running it,
- uploading a file produced by the executable
while assuming remote target user remote-target with homedir
/home/remote-target and remotedir set to /home/remote-target/tmp.
Concretely, it looks like this:
...
# binfile == "$outputs/gdb.abc/a.out"
set target_binfile [remote_download target $binfile]
# target_binfile == "/home/remote-target/tmp/a.out"
remote_exec target $target_binfile
# Running $target_binfile produced /home/remote-target/tmp/result.txt.
set result [remote_upload target /home/remote-target/tmp/result.txt \
$outputs/gdb.abc/result.txt]
# result == $outputs/gdb.abc/result.txt.
...
Add a remote_upload implementation that also handles remotedir in lib/gdb.exp,
overriding dejagnu's remote_upload, such that we can simplify the
remote_upload call to:
...
set result [remote_upload target result.txt $outputs/gdb.abc/result.txt]
...
Tested on x86_64-linux.
PR testsuite/30250
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30250
|
|
Procedure step_until from test gdb.reverse/step-indirect-call-thunk.exp
is moved to lib/gdb.exp and renamed repeat_cmd_until. The existing procedure
gdb_step_until in lib/gdb.exp is simpler variant of the new repeat_cmd_until
procedure. The existing procedure gdb_step_until is changed to just call
the new repeat_cmd_until procedure with the command set to "step" and an
optional CURRENT string. The default CURRENT string is set to "\}" to work
with the existing uses of procedure gdb_step_until.
|
|
With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) tstart^M
Target returns error code '.In-process agent library not loaded in process. \
Fast and static trace points unavailable.'.^M
(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: start trace experiment
...
Fix this by:
- handling remote host in gdb_load_shlib, and
- moving the gdb_load_shlib to after the clean_restart, such that the
set solib-search-path can take effect.
Tested on x86_64-linux.
|
|
Handle REMOTE_HOST_USERNAME in local-remote-host, similar to how that's done for
REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.
This helps to keep the home dir clean.
Since the setup makes $build/gdb/testsuite on build unreadable for the remote
host, we run into permission problems for GDB and the data-directory, so fix
this (as was done for gdbserver in gdbserver-base.exp) using file normalize.
Tested on x86_64-linux.
|
|
In proc have_avx we compile some source into an exec, resulting in a file $obj
on build, and then attempt to execute it on target:
...
set result [remote_exec target $obj]
...
Fix this by using gdb_remote_download target.
Likewise in a few other procs that use "remote_exec target".
Tested on x86_64-linux.
|
|
With test-case gdb.arch/i386-sse.exp (and likewise gdb.arch/i386-avx.exp) and
host board local-remote-host-notty and target board native-gdbserver I run
into:
...
gdb compile failed, i386-sse.c:68:10: fatal error: \
../lib/precise-aligned-alloc.c: No such file or directory
#include "../lib/precise-aligned-alloc.c"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
Fix this using '#include "precise-aligned-alloc.c"' and making that work with
non-remote and remote host.
Tested on x86_64-linux.
|
|
With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver, I run into:
...
FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
...
due to having:
...
$ readelf -d ftrace-insn-reloc | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: []
...
instead of:
...
$ readelf -d ftrace-insn-reloc | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN]
...
Handle this in escape_for_host.
Tested on x86_64-linux.
|
|
In gdb_compile we have:
...
lappend new_options "ldflags=-Wl,-rpath,\\\$ORIGIN"
...
and we could improve readability by using {} rather than "":
...
lappend new_options {ldflags=-Wl,-rpath,\$ORIGIN}
...
But rather than manually adding escapes in a string, add a new proc
escape_for_host that care of this for us, allowing us to write:
...
lappend new_options [escape_for_host {ldflags=-Wl,-rpath,$ORIGIN}]
...
Tested on x86_64-linux.
|
|
Currently gdb_ada_compile doesn't support remote host.
Make this explicit in allow_ada_tests.
Tested on x86_64-linux.
|
|
When running test-case gdb.arch/i386-pkru.exp with host board
local-remote-host-notty and target board native-gdbserver on openSUSE
Tumbleweed (with DEBUGINFOD_URLS set), I run into:
...
This GDB supports auto-downloading debuginfo from the following URLs:^M
<https://debuginfod.opensuse.org/>^M
Enable debuginfod for this session? (y or [n]) ^CQuit^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: runto: run to main
...
The problem is that the unsetenv for DEBUGINFOD_URLS in default_gdb_init:
...
# If DEBUGINFOD_URLS is set, gdb will try to download sources and
# debug info for f.i. system libraries. Prevent this.
unset -nocomplain ::env(DEBUGINFOD_URLS)
...
doesn't work on remote host.
Fix this by using "set debuginfod enabled off" for remote host.
Tested on x86_64-linux.
|
|
When running test-case gdb.tui/corefile-run.exp with both host and target board
local-remote-host-native.exp, we run into:
...
FAIL: gdb.tui/corefile-run.exp: load corefile
...
while this passes with USE_TUI=0.
The problem is that the TUI setup code uses "setenv TERM ansi", which has no
effect on remote host.
I can confirm this analysis by working around this problem in
local-remote-host-native.exp like this:
...
- spawn $RSH -t -l $username $remote $cmd
+ spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd"
...
For now, simply make TUI unsupported for remote host, by returning 0 in
prepare_for_tui.
Tested on x86_64-linux.
|
|
In test-case gdb.tui/corefile-run.exp, we have this bit:
...
require !use_gdb_stub
if { [target_info gdb_protocol] == "extended-remote" } {
untested "not supported"
return
}
...
So with target board native-gdbserver we get:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: !use_gdb_stub
...
and with target board native-extended-gdbserver instead:
...
UNTESTED: gdb.tui/corefile-run.exp: not supported
...
Fix this by:
- adding an optional argument target_description to proc
target_can_use_run_cmd
- handling the target_description == core &&
[target_info gdb_protocol] == "extended-remote" case in the proc
- using require {target_can_use_run_cmd core}
such that now in both cases we have:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: \
target_can_use_run_cmd core
...
Tested on x86_64-linux.
|
|
When running test-cases gdb.mi/*.exp with target board
remote-gdbserver-on-localhost, we run into a few fails.
Fix these (and make things more similar to the gdb.exp procs) by:
- factoring out mi_load_shlib out of mi_load_shlibs
- making mi_load_shlib use gdb_download_shlib, like
gdb_load_shlib
- factoring out mi_locate_shlib out of mi_load_shlib
- making mi_locate_shlib check for mi_spawn_id, like
gdb_locate_shlib
- using gdb_download_shlib and mi_locate_shlib in the test-cases.
Tested on x86_64-linux, with and without target board
remote-gdbserver-on-localhost.
|
