| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The previous commit fixed set/show args when used with
$_gdb_setting_str, this commit fixes set/show cwd.
Instead of using a scratch variable which is then pushed into the
current inferior from a set callback, move to the API that allows for
getters and setters, and store the value directly within the current
inferior.
Update the existing test to check the cwd setting.
|
|
I noticed that $_gdb_setting_str was not working with 'args', e.g.:
$ gdb -q --args /tmp/hello.x arg1 arg2 arg3
Reading symbols from /tmp/hello.x...
(gdb) show args
Argument list to give program being debugged when it is started is "arg1 arg2 arg3".
(gdb) print $_gdb_setting_str("args")
$1 = ""
This is because the 'args' setting is implemented using a scratch
variable ('inferior_args_scratch') which is updated when the user does
'set args ...'. There is then a function 'set_args_command' which is
responsible for copying the scratch area into the current inferior.
However, when the user sets the arguments via the command line the
scratch variable is not updated, instead the arguments are pushed
straight into the current inferior.
There is a second problem, when the current inferior changes the
scratch area is not updated, which means that the value returned will
only ever reflect the last call to 'set args ...' regardless of which
inferior is currently selected.
Luckily, the fix is pretty easy, set/show variables have an
alternative API which requires we provide some getter and setter
functions. With this done the scratch variable can be removed and the
value returned will now always reflect the current inferior.
While working on set/show args I also rewrote show_args_command to
remove the use of deprecated_show_value_hack.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
PR 13098 explains that if a user attempts to use a string with either
`printf' (or `eval'), gdb returns an error (inferior not running):
(gdb) printf "%s\n", "hello"
evaluation of this expression requires the target program to be active
However, the parser can certainly handle this case:
(gdb) p "hello"
$1 = "hello"
This discrepancy occurs because printf_c_string does not handle
this specific case. The passed-in value that we are attempting to print
as a string is TYPE_CODE_ARRAY but it's lval type is not_lval.
printf_c_string will only attempt to print a string from the value's
contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's
type is considered a string type:
if (value->type ()->code () != TYPE_CODE_PTR
&& value->lval () == lval_internalvar
&& c_is_string_type_p (value->type ()))
{
...
}
Otherwise, it attempts to read the value of the string from the target's
memory (which is what actually generates the "evaluation of this ..."
error message).
|
|
After this commit:
commit e2f620135d92f7cd670af4e524fffec7ac307666
Date: Thu Mar 30 13:26:25 2023 +0100
gdb/testsuite: change newline patterns used in gdb_test
There were some regressions in gdb.trace/*.exp tests when run with the
native-gdbserver board. This commit fixes these regressions.
All the problems are caused by unnecessary trailing newline characters
included in the patterns passed to gdb_test. After the above commit
the testsuite is stricter when matching trailing newlines, and so the
additional trailing newline characters are now causing the test to
fail. Fix by removing all the excess trailing newline characters.
In some cases this cleanup means we should use gdb_test_no_output,
I've done that where appropriate. In a couple of other places I've
made use of multi_line to better build the expected output pattern.
|
|
Running gdb.ada/verylong.exp shows a warning from the Ada compiler:
prog.adb:16:11: warning: file name does not match unit name, should be "main.adb" [enabled by default]
This patch fixes the problem, and another similar one in
unchecked_union.exp.
|
|
In this commit I propose that we add special handling for the '^' when
used at the start of a gdb_test pattern. Consider this usage:
gdb_test "some_command" "^command output pattern"
I think the intention here is pretty clear - run 'some_command', and
the output from the command should be exactly 'command output
pattern'.
After the previous commit which tightened up how gdb_test matches the
final newline and prompt we know that the only thing after the output
pattern will be a single newline and prompt, and the leading '^'
ensures that there's no output before 'command output pattern', so
this will do what I want, right?
... except it doesn't. The command itself will also needs to be
matched, so I should really write:
gdb_test "some_command" "^some_command\r\ncommand output pattern"
which will do what I want, right? Well, that's fine until I change
the command and include some regexp character, then I have to write:
gdb_test "some_command" \
"^[string_to_regexp some_command]\r\ncommand output pattern"
but this all gets a bit verbose, so in most cases I simply don't
bother anchoring the output with a '^', and a quick scan of the
testsuite would indicate that most other folk don't both either.
What I propose is this: the *only* thing that can appear immediately
after the '^' is the command converted into a regexp, so lets do that
automatically, moving the work into gdb_test. Thus, when I write:
gdb_test "some_command" "^command output pattern"
Inside gdb_test we will spot the leading '^' in the pattern, and
inject the regexp version of the command after the '^', followed by a
'\r\n'.
My hope is that given this new ability, folk will be more inclined to
anchor their output patterns when this makes sense to do so. This
should increase our ability to catch any unexpected output from GDB
that appears as a result of running a particular command.
There is one problem case we need to consider, sometime people do
this:
gdb_test "" "^expected output pattern"
In this case no command is sent to GDB, but we are still expecting
some output from GDB. This might be a result of some asynchronous
event for example. As there is no command sent to GDB (from the
gdb_test) there will be no command text to parse.
In this case my proposed new feature injects the command regexp, which
is the empty string (as the command itself is empty), but still
injects the '\r\n' after the command regexp, thus we end up with this
pattern:
^\r\nexpected output pattern
This extra '\r\n' is not what we should expected here, and so there is
a special case inside gdb_test -- if the command is empty then don't
add anything after the '^' character.
There are a bunch of tests that do already use '^' followed by the
command, and these can all be simplified in this commit.
I've tried to run all the tests that I can to check this commit, but I
am certain that there will be some tests that I manage to miss.
Apologies for any regressions this commit causes, hopefully fixing the
regressions will not be too hard.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit makes two changes to how we match newline characters in
the gdb_test proc.
First, for the newline pattern between the command output and the
prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.
The old pattern would spot multiple newlines, and so there are a few
places where, as part of this commit, I've needed to add an extra
trailing '\r\n' to the pattern in the main test file, where GDB's
output actually includes a blank line.
But I think this is a good thing. If a command produces a blank line
then we should be checking for it, the current gdb_test doesn't do
that. But also, with the current gdb_test, if a blank line suddenly
appears in the output, this is going to be silently ignored, and I
think this is wrong, the test should fail in that case.
Additionally, the existing pattern will happily match a partial
newline. There are a strangely large number of tests that end with a
random '.' character. Not matching a literal period, but matching any
single character, this is then matching half of the trailing newline
sequence, while the \[\r\n\]+ in gdb_test is matching the other half
of the sequence. I can think of no reason why this would be
intentional, I suspect that the expected output at one time included a
period, which has since been remove, but I haven't bothered to check
on this. In this commit I've removed all these unneeded trailing '.'
characters.
The basic rule of gdb_test after this is that the expected pattern
needs to match everything up to, but not including the newline
sequence immediately before the GDB prompt. This is generally how the
proc is used anyway, so in almost all cases, this commit represents no
significant change.
Second, while I was cleaning up newline matching in gdb_test, I've
also removed the '[\r\n]*' that was added to the start of the pattern
passed to gdb_test_multiple.
The addition of this pattern adds no value. If the user pattern
matches at the start of a line then this would match against the
newline sequence. But, due to the '*', if the user pattern doesn't
match at the start of a line then this group doesn't care, it'll
happily match nothing.
As such, there's no value to it, it just adds more complexity for no
gain, so I'm removing it. No tests will need updating as a
consequence of this part of the patch.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes
fail when run from a particular directory.
The test tries to find the number of the first internal breakpoint
using this proc:
proc get_first_maint_bp_num { } {
gdb_test_multiple "maint info break" "find first internal bp num" {
-re -wrap "(-\[0-9\]).*" {
return $expect_out(1,string)
}
}
return ""
}
The problem is, at the time we issue 'maint info break' there are both
internal breakpoint and non-internal (user created) breakpoints in
place. The user created breakpoints include the path to the source
file.
Sometimes, I'll be working from a directory that includes a number,
like '/tmp/blah-1/gdb/etc', in which case the pattern above actually
matches the '-1' from 'blah-1'. In this case there's no significant
problem as it turns out that -1 is the number of the first internal
breakpoint.
Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which
case the above pattern patches '-4' from 'blah-4'. It turns out this
is also not a problem -- the test doesn't actually need the first
internal breakpoint number, it just needs the number of any internal
breakpoint.
But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in
which case the pattern above matches '-0' from 'blah-0', and in this
case the test fails - there is no internal breakpoint '-0'.
Fix this by spotting that the internal breakpoint numbers always
occurs after a '\r\n', and that they never start with a 0. Our
pattern becomes:
-re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" {
return $expect_out(1,string)
}
After this I'm no longer seeing any failures.
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.
|
|
With test-case gdb.tui/completion.exp, we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/completion.exp: check focus completions
...
The timeout happens in this command:
...
Term::command "layout src"
...
which waits for:
- "(gdb) layout src", and then
- "(gdb) ".
Because the "layout src" command enables the TUI there's just a prompt.
Fix this by using Term::command_no_prompt_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.
|
|
With test-case gdb.tui/main.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/main.exp: show main after file
...
The problem is that this command:
...
Term::command "file [standard_output_file $testfile]"
...
tries to match "(gdb) $cmd", but due to the long file name, $cmd is split up
over two lines:
...
16 (gdb) file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/main/ma
17 in
18 Reading symbols from /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.t
19 ui/main/main...
20 (gdb)
...
Fix this by matching "Reading symbols from" instead.
Tested on x86_64-linux.
|
|
With test-case gdb.tui/corefile-run.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/corefile-run.exp: load corefile
...
The timeout happens in this command:
...
Term::command "core-file $core"
...
because it tries to match "(gdb) $cmd" but $cmd is split over two lines:
...
16 (gdb) core-file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/co
17 refile-run/corefile-run.core
18 [New LWP 5370]
19 Core was generated by `/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb
20 .tui/corefile-run/coref'.
21 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
22 #0 main () at tui-layout.c:21
23 (gdb)
...
Fix this by using send_gdb "$cmd\n" and wait_for "Program terminated" instead.
Tested on 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.
|
|
When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor
(emacs).
The problem is that this:
...
if { 1 } {
foo "{" "}"<ENTER>bar
}
...
produces this:
...
if { 1 } {
foo "{" "}"
bar
}
...
Note that this doesn't happen for "{}".
Fix this by using "\{" and "\}".
Tested on x86_64-linux.
|
|
On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with
-O2 -g -flto=auto, I run into:
...
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
Fix the first two FAILs by using $bkptno_numopt_re.
The last FAIL is due to:
...
(outer-gdb) print *type->main_type^M
A syntax error in expression, near `->main_type'.^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
because:
...
(outer-gdb) print type^M
Attempt to use a type name as an expression^M
...
Fix this by making the test unresolved if "print type" or
"print type->main_type" doesn't succeed.
On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with
-O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type
not hitting. Fix this by detecting the situation and bailing out.
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 using a compiler defaulting to -std=gnu90, we run into:
...
Running gdb.server/attach-flag.exp ...
gdb compile failed, attach-flag.c: In function 'main':
attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
in C99 or C11 mode
for (int i = 0; i < NTHREADS; i++)
^~~
attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
-std=gnu11 to compile your code
...
Fix this by using -std=gnu99.
Tested on x86_64-linux.
|
|
Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so
require this.
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.
|
|
Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
...
set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
...
but that's only supported starting tcl 8.6.
Fix this by using "expr" instead:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...
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.
|
|
[ Changes in v2:
- rebase on trunk
Changes in v3:
- add test-case ]
We should exclude matches to the ending PC to prevent false matches with the
next function, as prologue_end is located at the end PC.
<fun1>:
0x00: ... <-- start_pc
0x04: ...
0x08: ... <-- breakpoint
0x0c: ret
<fun2>:
0x10: ret <-- end_pc | prologue_end of fun2
Tested on x86_64-linux.
Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
Approved-by: Kevin Buettner <kevinb@redhat.com>
[1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
PR symtab/30369
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369
|
|
Directory gdb/testsuite/boards contains a number of host/target boards, which
run a test-case (or test-cases) in a different way.
The benefits of using these boards are:
- improving test coverage of gdb,
- making the testsuite more robust, and
- making sure the test-cases work for non-native and remote setups, if
possible.
Each board is slightly different, and developers need to learn how to use each
one, what parameters to pass and how, and which ones can be used in
combination with each other. This is a threshold to start using them.
And then there quite a few, so I suppose typically only a few will be used by
each developer.
Add script gdb/testsuite/make-check-all.sh, that's intended to function as a
drop-in replacement of make check, while excercising all host/target boards in
gdb/testsuite/boards.
An example of make-check-all.sh for one test-case is:
...
$ ~/gdb/src/gdb/testsuite/make-check-all.sh gdb.base/advance.exp
LOCAL:
# of expected passes 8
TARGET BOARD: cc-with-gdb-index
# of expected passes 8
...
HOST BOARD: local-remote-host-notty, TARGET BOARD: remote-stdio-gdbserver
# of expected passes 8
HOST/TARGET BOARD: local-remote-host-native
# of expected passes 8
...
Shell-checked and tested on x86_64-linux.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
call_site_target::iterate_over_addresses may look up a minimal symbol.
On platforms like PPC64 that use function descriptors, this may find
an unexpected address. The fix is to use gdbarch_convert_from_func_ptr_addr
to convert from a function descriptor to the address recorded at the
call site.
I've added a new test case that is based on the internal AdaCore test
that provoked this bug. However, I'm unable to test it as-is on
PPC64.
|
|
Change-Id: I849d10d69c254342bf01e955ffe62a2b60f9de4b
|
|
Prior to this patch, it's not possible for GDB to debug GPU code in fork
children or after an exec. The amd-dbgapi target attaches to processes
when an inferior appears due to a "run" or "attach" command, but not
after a fork or exec. This patch adds support for that, such that it's
possible to for an inferior to fork and for GDB to debug the GPU code in
the child.
To achieve that, use the inferior_forked and inferior_execd observers.
In the case of fork, we have nothing to do if `child_inf` is nullptr,
meaning that GDB won't debug the child. We also don't attach if the
inferior has vforked. We are already attached to the parent's address
space, which is shared with the child, so trying to attach would cause
problems. And anyway, the inferior can't do anything other than exec or
exit, it certainly won't start GPU kernels before exec'ing.
In the case of exec, we detach from the exec'ing inferior and attach to
the following inferior. This works regardless of whether they are the
same or not. If they are the same, meaning the execution continues in
the existing inferior, we need to do a detach/attach anyway, as
amd-dbgapi needs to be aware of the new address space created by the
exec.
Note that we use observers and not target_ops::follow_{fork,exec} here.
When the amd-dbgapi target is compiled in, it will attach (in the
amd_dbgapi_process_attach sense, not the ptrace sense) to native
inferiors when they appear, but won't push itself on the inferior's
target stack just yet. It only pushes itself if the inferior
initializes the ROCm runtime. So, if a non-GPU-using inferior calls
fork, an amd_dbgapi_target::follow_fork method would not get called.
Same for exec. A previous version of the code had the amd-dbgapi target
pushed all the time, in which case we could use the target methods. But
we prefer having the target pushed only when necessary, it's less
intrusive when doing native debugging that doesn't involve the GPU.
Change-Id: I5819c151c371120da8bab2fa9cbfa8769ba1d6f9
Reviewed-By: Pedro Alves <pedro@palves.net>
|
|
This adds support for 128-bit integers to the Ada parser.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30188
|
|
These helper functions in the Ada parser don't seem all that
worthwhile to me, so this patch removes them.
|
|
This adds support for 128-bit integers to the Rust parser.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21185
|
|
With DWARF 5, it's possible to produce an empty file name in the File Name
Table of the .debug_line section:
...
The File Name Table (offset 0x112, lines 1, columns 2):
Entry Dir Name
0 1 (indirect line string, offset: 0x2d):
...
Currently, when gdb reads an exec containing such debug info, it segfaults:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
gdb/dwarf2/read.c:18716
18716 if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
...
because read_direct_string transforms "" into a nullptr, and we end up
dereferencing the nullptr.
Note that the behaviour of read_direct_string has been present since repo
creation.
Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
filenames.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
PR symtab/30357
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357
|
|
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>
|
|
(1) Description of problem
In the current code, when execute the following test on LoongArch:
$make check-gdb TESTS="gdb.base/dump.exp"
```
FAIL: gdb.base/dump.exp: dump array as value, intel hex
FAIL: gdb.base/dump.exp: dump struct as value, intel hex
FAIL: gdb.base/dump.exp: dump array as memory, ihex
FAIL: gdb.base/dump.exp: dump struct as memory, ihex
```
These tests passed on the X86_64,
(2) Root cause
On LoongArch, variable intarray address 0x120008068 out of range for IHEX,
so dump ihex test failed.
gdb.base/dump.exp has the following code to check 64-bit address
```
# Check the address of a variable. If it is bigger than 32-bit,
# assume our target has 64-bit addresses that are not supported by SREC,
# IHEX and TEKHEX. We skip those tests then.
set max_32bit_address "0xffffffff"
set data_address [get_hexadecimal_valueof "&intarray" 0x100000000]
if {${data_address} > ${max_32bit_address}} {
set is64bitonly "yes"
}
```
We check the "&intarray" on different target as follow:
```
$gdb gdb/testsuite/outputs/gdb.base/dump/dump
...
(gdb) start
...
On X86_64:
(gdb) print /x &intarray
$1 = 0x404060
On LoongArch:
(gdb) print /x &intarray
$1 = 0x120008068
```
The variable address difference here is due to the link script
of linker.
```
On X86_64:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
On LoongArch:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000));
. = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS;
```
(3) How to fix
Because 64-bit variable address out of range for IHEX, it's not an
functional problem for LoongArch. Refer to the handling of 64-bit
targets in this testsuite, use the "is64bitonly" flag to skip those
tests for the target has 64-bit addresses.
Signed-off-by: Hui Li <lihui@loongson.cn>
Approved-By: Tom Tromey <tom@tromey.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Add regression tests for PR30325, one for the asm window and one for the
source window.
Use maint set tui-left-margin verbose to make the extend of the left margin
clear.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I found a couple of tests that check gnatmake_version_at_least using
"if" where "require" would be a little cleaner. This patch converts
these.
|
|
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.
|
|
On amd64 (at least) if a user sets a watchpoint before the inferior
has started then GDB will assume that a hardware watchpoint can be
created.
When the inferior starts there is a chance that the watchpoint can't
actually be create as a hardware watchpoint, in which case (currently)
GDB will silently convert the watchpoint to a software watchpoint.
Here's an example session:
(gdb) p sizeof var
$1 = 4000
(gdb) watch var
Hardware watchpoint 1: var
(gdb) info watchpoints
Num Type Disp Enb Address What
1 hw watchpoint keep y var
(gdb) starti
Starting program: /home/andrew/tmp/watch
Program stopped.
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) info watchpoints
Num Type Disp Enb Address What
1 watchpoint keep y var
(gdb)
Notice that before the `starti` command the watchpoint is showing as a
hardware watchpoint, but afterwards it is showing as a software
watchpoint. Additionally, note that we clearly told the user we
created a hardware watchpoint:
(gdb) watch var
Hardware watchpoint 1: var
I think this is bad. I used `starti`, but if the user did `start` or
even `run` then the inferior is going to be _very_ slow, which will be
unexpected -- after all, we clearly told the user that we created a
hardware watchpoint, and the manual clearly says that hardware
watchpoints are fast (at least compared to s/w watchpoints).
In this patch I propose adding a new warning which will be emitted
when GDB downgrades a h/w watchpoint to s/w. The session now looks
like this:
(gdb) p sizeof var
$1 = 4000
(gdb) watch var
Hardware watchpoint 1: var
(gdb) info watchpoints
Num Type Disp Enb Address What
1 hw watchpoint keep y var
(gdb) starti
Starting program: /home/andrew/tmp/watch
warning: watchpoint 1 downgraded to software watchpoint
Program stopped.
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) info watchpoints
Num Type Disp Enb Address What
1 watchpoint keep y var
(gdb)
The important line is:
warning: watchpoint 1 downgraded to software watchpoint
It's not much, but hopefully it will be enough to indicate to the user
that something unexpected has occurred, and hopefully, they will not
be surprised when the inferior runs much slower than they expected.
I've added an amd64 only test in gdb.arch/, I didn't want to try
adding this as a global test as other architectures might be able to
support the watchpoint request in h/w.
Also the test is skipped for extended-remote boards as there's a
different set of options for limiting hardware watchpoints on remote
targets, and this test isn't about them.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
I was seeing some failures in gdb.threads/omp-par-scope.exp when run
on a riscv64 target. It turns out the cause of the problem is that I
didn't have debug information installed for libgomp.so, which this
test makes use of. The test requires GDB to backtrace through a
libgomp function, and the riscv prologue unwinder was failing to
unwind this particular stack frame.
The reason for the failure to unwind was that the function prologue
includes a c.li (compressed load immediate) instruction, and the riscv
prologue scanning unwinder doesn't know what to do with this
instruction, though the unwinder does understand c.lui (compressed
load unsigned immediate).
This commit adds support for c.li. After this GDB is able to unwind
through libgomp, and I no longer see any unexpected failures in
gdb.threads/omp-par-scope.exp.
I've also included a new test in gdb.arch/ which specifically checks
for our c.li support.
|
|
I noticed there aren't any Ada test cases for setting a breakpoint
using a label. This patch adds one, adapted from the AdaCore test
suite.
|
|
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.
|
|
gdb.arch/amd64-disp-step-self-call.exp
For test-case gdb.arch/amd64-disp-step-self-call.exp I get:
...
gdb compile failed, ld: warning: amd64-disp-step-self-call0.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
...
Fix this by adding the missing .note.GNU-stack.
Likewise for gdb.arch/i386-disp-step-self-call.exp.
Tested on x86_64-linux.
|
|
This commit:
commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
Date: Wed Feb 22 12:15:34 2023 +0000
gdb: fix reg corruption from displaced stepping on amd64
Added two test scripts gdb.arch/amd64-disp-step-self-call.exp and
gdb.arch/i386-disp-step-self-call.exp. These scripts contained a test
that included a stack address in the test name, this makes it harder
to compare results between runs.
This commit gives the tests proper names that doesn't include an
address.
Also in gdb.arch/i386-disp-step-self-call.exp I noticed that we were
writing 8-bytes rather than 4 in order to clear the return address
entry on the stack. This is also fixed in this commit.
|
|
Clang with LTO (clang -flto) garbage collects unused global variables,
Thus, gdb.base/align-c.exp and gdb.base/align-c++.exp fail with
hundreds of FAILs like so:
$ make check \
TESTS="gdb.*/align-*.exp" \
RUNTESTFLAGS="CC_FOR_TARGET='clang -flto' CXX_FOR_TARGET='clang++ -flto'"
...
FAIL: gdb.base/align-c.exp: get integer valueof "a_char"
FAIL: gdb.base/align-c.exp: print _Alignof(char)
FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_char"
FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_char)
FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_unsigned_char"
...
AIX GCC has the same issue, and there the easier way of adding
__attribute__((used)) to globals does not help.
So add explicit uses of all globals to the generated code.
For the C++ test, that reveals that the static variable members of the
generated structs are not defined anywhere, leading to undefined
references. Fixed by emitting initialization for all static members.
Lastly, I noticed that CXX_FOR_TARGET was being ignored -- that's
because the align-c++.exp testcase is compiling with the C compiler
driver. Fixed by passing "c++" as option to prepare_for_testing.
Change-Id: I874b717afde7b6fb1e45e526912b518a20a12716
|
|
This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.
The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.
I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on. Currently, if
the second argument is of the wrong type then we get this error:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Second argument must be block.
Error while executing Python code.
(gdb)
After this commit, we now get an error like this:
(gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 2 must be gdb.Block, not str
Error while executing Python code.
(gdb)
Changes are:
1. Exception type is TypeError not RuntimeError, this is unfortunate
as user code _could_ be relying on this, but I think the improvement
is worth the risk, user code relying on the exact exception type is
likely to be pretty rare,
2. New error message gives argument position and expected argument
type, as well as the type that was passed.
If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above. If the first argument has the wrong type then
before this commit we saw this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: Argument must be a symbol or string.
Error while executing Python code.
(gdb)
And after we see this:
(gdb) python print(gdb.selected_frame().read_var(123))
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: argument 1 must be gdb.Symbol or str, not int
Error while executing Python code.
(gdb)
For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Following on from the previous commit, this updates
Frame.read_register to accept named arguments. As with the previous
commit there's no huge benefit for the users in accepting named
arguments here -- this function only takes a single argument after
all.
But I do think it is worth keeping Frame.read_register method in sync
with the PendingFrame.read_register method, this allows for the
possibility that the user has some code that can operate on either a
Frame or a Pending frame.
Minor update to allow for named arguments, and an extra test to check
the new functionality.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
