| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch integrates GNU poke (http://jemarch.net/poke) in GDB by
mean of libpoke. It allows the GDB user to execute Poke code from
within the debugger with access to the target memory, types and
values.
How this stuff works:
- GDB links with libpoke.so and uses the interface in libpoke.h.
This is also how the GNU poke application (the command-line
editor) is implemented.
- There are three commands:
poke STR
poke-add-type EXPR
poke-add-types REGEXP
poke-dump-types
All three commands make sure to start the poke incremental
compiler if it isn't running already.
- Access to the target's memory is provided by GDB by installing
a Foreign IO device in the incremental compiler. This is
`iod_if' in poke.c.
- Access to the terminal is provided by GDB by providing a
pk_term_if implementation to the incremental compiler. This is
`poke_term_if' in poke.c.
- Access to GDB values is provided by GDB by installing an alien
token handler in the incremental compiler. This is
`poke_alien_token_handler' in poke.c.
gdb/ChangeLog:
2021-05-10 Jose E. Marchesi <jose.marchesi@oracle.com>
* configure.ac: Support --enable-poke.
* configure: Regenerate.
* Makefile.in (POKE_OBS): Define based on @POKE_OBS@.
(DEPFILES): Add POKE_OBS.
* poke.c: New file.
gdb/doc/ChangeLog:
2021-05-10 Jose E. Marchesi <jose.marchesi@oracle.com>
* Makefile.in (GDB_DOC_FILES): Add poke.texi.
* poke.texi: New file.
* gdb.texinfo (Data): Add meny entry for Poke and @include poke.texi.
|
|
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.
|
|
This commit addresses PR gdb/7946. While checking for bugs relating
to the jump command I noticed a long standing bug that points out a
deficiency with GDB's documentation of the jump command.
The bug points out that 'jump 0x...' is not always the same as 'set
$pc = 0x...' and then 'continue'. Writing directly to the $pc
register does not update any auxiliary state, e.g. $npc on SPARC,
while using 'jump' does.
It felt like this would be an easy issue to address by adding a
paragraph to the docs, so I took a stab at writing something suitable.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7946
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
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>
|
|
While working on a later patch in this series, which tightens up some
of our pattern matching when using gdb_test, I ran into some failures
caused by some warnings having a trailing newline character.
The warning function already adds a trailing newline, and it is my
understanding that we should not be adding a second by including a
newline at the end of any warning message.
The problem cases I found were in language.c and remote.c, in this
patch I fix the cases I hit, but I also checked all the other warning
calls in these two files and removed any additional trailing newlines
I found.
In remote.c the warning actually had a newline character in the middle
of the warning message (in addition to the trailing newline), which
I've removed. I don't think it's helpful to forcibly split a warning
as was done here -- in the middle of a sentence. Additionally, the
message isn't even that long (71 characters), so I think removing this
newline is an improvement.
None of the expected test result need updating with this commit,
currently the patterns in gdb_test will match one or more newline
sequences, so the tests are as happy with one newline (after this
commit) as they are with two newlines (before this commit). A later
commit will change gdb_test so that it is not so forgiving, and these
warnings would have caused some failures.
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>
|
|
Add a marker in the documentation for indexing the $_inferior_thread_count
variable.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
In commit 5d10a2041eb ("gdb: add string_file::release method") this was added:
...
+ std::string string_val = string.release ();
...
without updating subsequent uses of string.size (), which returns 0 after the
string.release () call.
Fix this by:
- using string_val.size () instead of string.size (), and
- adding an assert that would have caught this regression.
Tested on x86_64-linux.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
PR tui/30389
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30389
|
|
Simon pointed out that the recent changes to gdb_mpz caused a build
failure on amd64 macOS. It turns out to be somewhat difficult to
overload a method in a way that will work "naturally" for all integer
types; especially in a case like gdb_mpz::operator==, where it's
desirable to special case all integer types that are no wider than
'long'.
After a false start, I came up with this patch, which seems to work.
It applies the desirable GMP special cases directly in the body,
rather than via overloads.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
There are two new debug architecture version entries. I updated the
code for Linux, but fbsd also needs updating.
This patch does this, and should be pretty straightforward.
I can't test this on native fbsd, but I'm fairly confident it should
work.
Signed-off-by: Luis Machado <luis.machado@arm.com>
|
|
Teach gdb about a new debug architecture version for AArch64 (0x11).
No user-visible changes.
Regression-tested on aarch64-linux Ubuntu 20.04/22.04.
Signed-off-by: Luis Machado <luis.machado@arm.com>
|
|
One spot in varobj.c should use scoped_restore to save and restore
input_radix. Note that the current code may fail to restore it on
error, so this patch fixes a latent bug.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
parser_state::push_dollar has some unnecessary "goto"s. Replacing
them cleans up the code. Regression tested on x86-64 Fedora 36.
Approved-By: Simon Marchi <simon.marchi@efficios.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.
|
|
I noticed that this observable was never notified, which means we can
probably safely remove it. The notification was removed in:
commit 243a925328f8e3184b2356bee497181049c0174f
Author: Pedro Alves <palves@redhat.com>
Date: Wed Sep 9 18:23:24 2015 +0100
Replace "struct continuation" mechanism by something more extensible
print_end_stepping_range_reason in turn becomes unused, so remote it as
well.
Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a
|
|
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
|
|
I think that the language_auto enumerator and the auto_language class
can be removed. There isn't really an "auto" language, it's only a
construct of the "set language" command to say "pick the appropriate
language automatically". But "auto" is never the current language. The
`current_language` points to the current effective language, and the
fact that we're in "auto language" mode is noted by the language_mode
global.
- Change set_language to handle the "auto" (and "local", which is a
synonym) early, instead of in the for loop. I think it makes the two
cases (auto vs explicit language) more clearly separated anyway.
- Adjust add_set_language_command to hard-code the "auto" string,
instead of using the "auto" language definition.
- Remove auto_language, rename auto_or_unknown_language to
unknown_language and move the bits of the existing unknown_language
in there.
- Remove the set_language at the end of _initialize_language. I think
it's not needed, because we call set_language in gdb_init, after all
_initialize functions are called. There is some chance that an
_initialize function that runs after _initialize_language implicitly
depends on current_language being set, but my testsuite runs haven't
found anything like that.
- Use language_unknown instead of language_auto when creating a minimal
symbol (minimal_symbol_reader::record_full). I think that this value
is used to indicate that we don't know the symbol of the minimal
symbol (yet), so language_unknown makes sense to me. Update a
condition accordingly in ada-lang.c. symbol_find_demangled_name also
appears to "normalize" this value from "unknown" to "auto", remove
that part and update the condition to just check for
language_unknown.
Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The `language` global variable is mostly a scratch variable used for the
setting. The source of truth is really current_language and
language_mode (auto vs manual), which are set by the
set_language_command callback.
Switch the setting to use the add_setshow_enum_cmd overload that takes a
value getter and setter.
Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
set_language returns the previous language, but nothing uses it. Remove
the return value. This lets us remove the assignment to
current_language, in _initialize_language.
Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
While working on PRs tui/30337 and cli/30346 I came across various notions of
width in gdb, as reported by gdb, readline, curses and the environment
variables.
As for gdb, readline and the environment variables, the way things work
is:
- Gdb asks readline to detect screen size,
- readline sets the actual screen size in the environment variables
COLUMNS and LINES,
- readline reports back a screen size to gdb, which may have one column
less than the actual screen size, to deal with lack of auto-wrap.
This becomes gdb's notion of screen size (in other words the point where
we can expect the gdb command line to wrap),
- Gdb then explicitly sets readline's screen size, which readline itself may
adjust to deal with lack of auto-wrap. This becomes readlines notion
of screen size (well, internally the unadjusted one, but it'll report back
the adjusted one).
Add a command "maint info screen" that prints these notions, both for width
and height.
For TERM=xterm we have:
...
$ TERM=xterm gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 118.
Number of characters readline reports are in a line is 118.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...
And for TERM=ansi:
...
$ TERM=ansi gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 117.
Number of characters readline reports are in a line is 116.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...
[ The fact that we have "characters readline reports are in a line is 116" is
is due to gdb making readline adjust twice for the lack of auto-wrap, this is
PR cli/30346.
Likewise we can detect tui/30337 by doing a resize in TUI mode and doing
"maint info screen":
...
Number of characters characters curses thinks are in a line is 110.
Number of characters environment thinks are in a line is 111 (COLUMNS). ]
And for TERM=ansi, with width and heigth set to 0:
...
Number of characters gdb thinks are in a line is 4294967295 (unlimited).
Number of characters readline reports are in a line is 32766 (unlimited - 1).
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 4294967295 (unlimited).
Number of lines readline reports are in a page is 32767 (unlimited).
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...
[ Note that when doing a resize by say maximizing or de-maximizing a terminal,
all reported values are updated, except for curses when not in TUI mode.
Maybe that means there's a bug. If not, then maybe we should not print
the curses lines unless in TUI mode, or annotate those lines such that it's
clear that the values may be not up-to-date. ]
I'd like to use this command in the regression test for PR cli/30346.
Tested on x86_64-linux.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
AdaCore has a local patch for PPC "finish", but last year, Ulrich
Weigand pointed out that this patch was incorrect. It may work for
simple functions like the one in the internal test, but nothing
guarantees that r3 will be preserved by the callee, so checking r3 on
exit is not always correct.
This patch fixes the problem using the same approach as PPC64: use the
entry value of r3, if available. Ulrich confirmed this matches the
PPC32 ABI.
|
|
On PPC64, with the test case included in an earlier patch, we found
that "finish" would still not correctly find the return value via
entry values.
The issue is simple. The compiler emits:
0x00000000100032b8 <+28>: bl 0x1000320c <pck__create_large>
0x00000000100032bc <+32>: nop
0x00000000100032c0 <+36>: li r9,42
... but the DWARF says:
<162a> DW_AT_call_return_pc: 0x100032c0
That is, the declared return PC is one instruction past the actual
return PC.
This patch adds a new arch hook to handle this scenario, and
implements it for PPC64. Some care is taken so that GDB will continue
to work if this compiler bug is fixed. A GCC patch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html
No check for 'nop' is done, as subsequent discussion revealed that the
linker might replace this with another instruction.
|
|
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.
|
|
I happened across adjust_type_signedness, which may be used to modify
a type when printing an Ada value. Modifying a type like this is a
bad idea -- they should normally be considered immutable. Removing
this function still passes both the dejagnu and internal AdaCore
tests, though, so this patch drops it.
As this was reviewed internally, and only affect Ada, I am checking it
in.
|
|
Change-Id: I849d10d69c254342bf01e955ffe62a2b60f9de4b
|
|
PowerPC supports two 128-bit floating point formats, the IBM long double
and IEEE 128-bit float. The issue is the DWARF information does not
distinguish between the two. There have been proposals of how to extend
the DWARF information as discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
but has not been fully implemented.
GCC introduced the _Float128 internal type as a work around for the issue.
The workaround is not transparent to GDB. The internal _Float128 type
name is printed rather then the user specified long double type. This
patch adds a new gdbarch method to allow PowerPC to detect the GCC
workaround. The workaround checks for "_Float128" name when reading the
base typedef from the die_info. If the workaround is detected, the type
and format fields from the _Float128 typedef are copied to the long
double typedef. The same is done for the complex long double typedef.
This patch fixes 74 regression test failures in
gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
default on GCC. It fixes one regression test failure in
gdb.base/complex-parts.exp.
The patch has been tested on Power 10 where GCC defaults to IEEE Float
128-bit and on Power 10 where GCC defaults to the IBM 128-bit float. The
patch as also been tested on X86-64 with no new regression failures.
|
|
I noticed some unnecessary casts to LONGEST in ada-lang.c. This patch
removes the ones I think are very clearly not needed. I'm checking
this in as obvious.
|
|
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>
|
|
The problem explained and fixed in the previous patch could have also
been fixed by this patch. But I think it's good change anyhow, that
could prevent future bugs, so here it is.
fetch_inferior_event switches to an arbitrary (in practice, the first) inferior
of the process target of the inferior used to fetch the event. The idea is
that the event handling code will need to do some target calls, so we want to
switch to an inferior that has target target.
However, you can have two inferiors that share a process target, but with one
inferior having an additional target on top:
inf 1 inf 2
----- -----
another target
process target process target
exec exec
Let's say inferior 2 is selected by do_target_wait and returns an event that is
really synthetized by "another target". This "another target" could be a
thread or record stratum target (in the case explained by the previous patch,
it was the arch stratum target, but it's because the amd-dbgapi abuses the arch
layer). fetch_inferior_event will then switch to the first inferior with
"process target", so inferior 1. handle_signal_stop then tries to fetch the
thread's registers:
ecs->event_thread->set_stop_pc
(regcache_read_pc (get_thread_regcache (ecs->event_thread)));
This will try to get the thread's register by calling into the current target
stack, the stack of inferior 1. This is problematic because "another target"
might have a special fetch_registers implementation.
I think it would be a good idea to switch to the inferior for which the
even was reported, not just some inferior of the same process target.
This will ensure that any target call done before we eventually call
context_switch will be done on the full target stack that reported the
event.
Not all events are associated to an inferior though. For instance,
TARGET_WAITKIND_NO_RESUMED. In those cases, some targets return
null_ptid, some return minus_one_ptid (ideally the expected return value
should be clearly defined / documented). So, if the ptid returned is
either of these, switch to an arbitrary inferior with that process
target, as before.
Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af
Reviewed-By: Pedro Alves <pedro@palves.net>
|
|
With the following patch, which teaches the amd-dbgapi target to handle
inferiors that fork, we end up with target stacks in the following
state, when an inferior that does not use the GPU forks an inferior that
eventually uses the GPU.
inf 1 inf 2
----- -----
amd-dbgapi
linux-nat linux-nat
exec exec
When a GPU thread from inferior 2 hits a breakpoint, the following
sequence of events would happen, if it was not for the current patch.
- we start with inferior 1 as current
- do_target_wait_1 makes inferior 2 current, does a target_wait, which
returns a stop event for an amd-dbgapi wave (thread).
- do_target_wait's scoped_restore_current_thread restores inferior 1 as
current
- fetch_inferior_event calls switch_to_target_no_thread with linux-nat
as the process target, since linux-nat is officially the process
target of inferior 2. This makes inferior 1 the current inferior, as
it's the first inferior with that target.
- In handle_signal_stop, we have:
ecs->event_thread->suspend.stop_pc
= regcache_read_pc (get_thread_regcache (ecs->event_thread));
context_switch (ecs);
regcache_read_pc executes while inferior 1 is still the current one
(because it's before the `context_switch`). This is a problem,
because the regcache is for a ptid managed by the amd-dbgapi target
(e.g. (12345, 1, 1)), a ptid that does not make sense for the
linux-nat target. The fetch_registers target call goes directly
to the linux-nat target, which gets confused.
- We would then get an error like:
Couldn't get extended state status: No such process.
... since linux-nat tries to do a ptrace call on tid 1.
GDB should switch to the inferior the ptid belongs to before doing the
target call to fetch registers, to make sure the call hits the right
target stack (it should be handled by the amd-dbgapi target in this
case). In fact the following patch does this change, and it would be
enough to fix this specific problem.
However, I propose to change regcache to make it switch to the right
inferior, if needed, before doing target calls. That makes the
interface as a whole more independent of the global context.
My first attempt at doing this was to find an inferior using the process
stratum target and the ptid that regcache already knows about:
gdb::optional<scoped_restore_current_thread> restore_thread;
inferior *inf = find_inferior_ptid (this->target (), this->ptid ());
if (inf != current_inferior ())
{
restore_thread.emplace ();
switch_to_inferior_no_thread (inf);
}
However, this caused some failures in fork-related tests and gdbserver
boards. When we detach a fork child, we may create a regcache for the
child, but there is no corresponding inferior. For instance, to restore
the PC after a displaced step over the fork syscall. So
find_inferior_ptid would return nullptr, and
switch_to_inferior_no_thread would hit a failed assertion.
So, this patch adds to regcache the information "the inferior to switch
to to makes target calls". In typical cases, it will be the inferior
that matches the regcache's ptid. But in some cases, like the detached
fork child one, it will be another inferior (in this example, it will be
the fork parent inferior).
The problem that we witnessed was in regcache::raw_update specifically,
but I looked for other regcache methods doing target calls, and added
the same inferior switching code to raw_write too.
In the regcache constructor and in get_thread_arch_aspace_regcache,
"inf_for_target_calls" replaces the process_stratum_target parameter.
We suppose that the process stratum target that would be passed
otherwise is the same that is in inf_for_target_calls's target stack, so
we don't need to pass both in parallel. The process stratum target is
still used as a key in the `target_pid_ptid_regcache_map` map, but
that's it.
There is one spot that needs to be updated outside of the regcache code,
which is the path that handles the "restore PC after a displaced step in
a fork child we're about to detach" case mentioned above.
regcache_test_data needs to be changed to include full-fledged mock
contexts (because there now needs to be inferiors, not just targets).
Change-Id: Id088569ce106e1f194d9ae7240ff436f11c5e123
Reviewed-By: Pedro Alves <pedro@palves.net>
|
|
Add the maybe_switch_inferior function, which ensures that the given
inferior is the current one. Return an instantiated
scoped_restore_current_thread object only we actually needed to switch
inferior.
Returning a scoped_restore_current_thread requires it to be
move-constructible, so give it a move constructor.
Change-Id: I1231037102ed6166f2530399e8257ad937fb0569
Reviewed-By: Pedro Alves <pedro@palves.net>
|
