| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is similar to the previous patch, but for gdb_protocol_is_remote.
gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint
print target-stack", which is unnecessary when checking whether
gdb_protocol is "remote" or "extended-remote" would do. Checking
gdb_protocol is more efficient, and can be done before starting GDB
and running to main, unlike gdb_is_target_remote/mi_is_target_remote.
This adds a new gdb_protocol_is_remote procedure, and uses it in place
of gdb_is_target_remote/mi_is_target_remote throughout.
There are no uses of gdb_is_target_remote/mi_is_target_remote left
after this. Those will be eliminated in a following patch.
In some spots, we no longer need to defer the check until after
starting GDB, so the patch adjusts accordingly.
Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef
Approved-By: Tom Tromey <tom@tromey.com>
|
|
gdb_is_target_native uses "maint print target-stack", which is
unnecessary when checking whether gdb_protocol is empty would do.
Checking gdb_protocol is more efficient, and can be done before
starting GDB and running to main, unlike gdb_is_target_native.
This adds a new gdb_protocol_is_native procedure, and uses it in place
of gdb_is_target_native.
At first, I thought that we'd end up with a few testcases needing to
use gdb_is_target_native still, especially multi-target tests that
connect to targets different from the default board target, but no,
actually all uses of gdb_is_target_native could be converted.
gdb_is_target_native will be eliminated in a following patch.
In some spots, we no longer need to defer the check until after
starting GDB, so the patch adjusts accordingly.
Change-Id: Ia706232dbffac70f9d9740bcb89c609dbee5cee3
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Factor the test for libc debug info out of gdb.base/relativedebug.exp to
a new procedure.
Also, change the "info sharedlibrary" test to explicitly detect when
libc has debug info.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Consider the following test-case:
...
$ cat hello.c
int main()
{
printf("hello ");
#include "world.inc"
$ cat world.inc
printf("world\n");
return 0;
}
$ gcc -g hello.c
...
The line table for the compilation unit, consisting just of
function main, is translated into these two gdb line tables, one for hello.c
and one for world.inc:
...
compunit_symtab: hello.c
symtab: hello.c
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 3 0x400557 0x400557 Y
1 4 0x40055b 0x40055b Y
2 END 0x40056a 0x40056a Y
compunit_symtab: hello.c
symtab: world.inc
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 1 0x40056a 0x40056a Y
1 2 0x400574 0x400574 Y
2 3 0x400579 0x400579 Y
3 END 0x40057b 0x40057b Y
...
The epilogue of main starts at 0x400579:
...
400579: 5d pop %rbp
40057a: c3 ret
...
Now, say we have an epilogue_begin marker in the line table at 0x400579.
We won't find it using find_epilogue_using_linetable, because it does:
...
const struct symtab_and_line sal = find_pc_line (start_pc, 0);
...
which gets us the line table for hello.c.
Fix this by using "find_pc_line (end_pc - 1, 0)" instead.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
PR symtab/31622
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622
|
|
runto uses a hard-coded timeout of 30s in its invocation of gdb_expect.
This is normally fine, but for very a slow system (e.g., an emulator) it
may not be enough time for GDB to reach the intended breakpoint.
gdb_expect can obtain a timeout value from user-configurable variables
when it's not given one explicitly, so use that mechanism instead since
the user will have already adjusted the timeout variable to account for
the slow system.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On SLE-11, with an older dejagnu version, I ran into:
...
Running gdb.ada/mi_prot.exp ...
UNRESOLVED: gdb.ada/mi_prot.exp: \
testcase aborted due to invalid command name: gdb_find_gnatmake
ERROR: tcl error sourcing gdb.ada/mi_prot.exp.
ERROR: invalid command name "gdb_find_gnatmake"
while executing
"::gdb_tcl_unknown gdb_find_gnatmake"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::gdb_tcl_unknown $args"
(procedure "::unknown" line 5)
invoked from within
"gdb_find_gnatmake"
(procedure "gnatmake_version_at_least" line 2)
invoked from within
...
Proc gdb_find_gnatmake is actually a backup for find_gnatmake:
...
if {[info procs find_gnatmake] == ""} {
rename gdb_find_gnatmake find_gnatmake
...
so gnatmake_version_at_least should use find_gnatmake instead.
For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we
don't run into this error.
For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to
find_gnatmake, and we do run into the error.
It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it
seems something legitimate to use. Maybe we should use future_ or gdb_future_
prefix instead to make this more clear, but I've left that alone for now.
Fix this by:
- triggering the same error with a recent dejagnu by removing
gdb_find_gnatmake unless used (and likewise for other procs in future.exp),
and
- using find_gnatmake in gnatmake_version_at_least.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31647
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647
|
|
Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw
MemoryError in inferior.read_memory if malloc fails") introduced
AddressSanitizer allocation-size-too-big errors in the two test-cases
affected by this commit.
Fix this by suppressing the error in the two test-cases using
allocator_may_return_null=1.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html
|
|
Dummy CUs help detect errors and are very helpful. However, the DWARF
spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to
the header. This patch adds that.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Approved-By: Tom de Vries <tdevries@suse.de>
Tested-By: Tom de Vries <tdevries@suse.de>
|
|
The dwarf standard requires that every line number program sequence ends
with a DW_LNE_end_sequence instruction.
Enforce this in the dwarf assembler for the last sequence in a line number
program (we have no means to enforce this for earlier sequences), and fix a
few test-case that don't have it.
Tested on aarch64-linux.
PR testsuite/31618
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31618
|
|
No address update before a DW_LNS_copy might mean an incorrect dwarf
assembly test-case.
Try to catch such incorrect dwarf assembly test-cases by:
- requiring an explicit address update for each DW_LNS_copy, and
- handling the cases where an update is indeed not needed, by adding
"DW_LNS_advance_pc 0".
Tested on aarch64-linux.
|
|
With test-case gdb.dwarf2/dw2-epilogue-begin.exp, we have an end_sequence
entry with the same address as the line entry before it:
...
File name Line number Starting address View Stmt
dw2-epilogue-begin.c 44 0x4101e8 x
dw2-epilogue-begin.c 47 0x4101ec x
dw2-epilogue-begin.c - 0x4101ec
...
and consequently the line entry is removed by gdb:
...
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PRO EPI
0 20 0x00000000004101a8 0x00000000004101a8 Y Y Y
1 27 0x00000000004101b0 0x00000000004101b0 Y
2 32 0x00000000004101b8 0x00000000004101b8 Y Y
3 34 0x00000000004101c0 0x00000000004101c0 Y Y
4 35 0x00000000004101c8 0x00000000004101c8 Y
5 40 0x00000000004101d4 0x00000000004101d4 Y Y
6 44 0x00000000004101e8 0x00000000004101e8 Y
7 END 0x00000000004101ec 0x00000000004101ec Y
...
This is a common mistake in dwarf assembly test-cases.
Fix this by:
- requiring an address update for each DW_LNE_end_sequence, and
- fixing the test-cases where that triggers an error.
I also encountered the error in test-case gdb.dwarf2/dw2-bad-elf.exp, and in
this case I worked around it using "DW_LNS_advance_pc 0".
Tested on aarch64-linux.
PR testsuite/31592
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31592
|
|
On debian 12, I run into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
relaying data between gdb and process 618591^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib/ld-linux-aarch64.so.1...^M
(No debugging symbols found in /lib/ld-linux-aarch64.so.1)^M
0x000000000401a980 in ?? () from /lib/ld-linux-aarch64.so.1^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
The problem is that we're expecting to match either of these regexps:
...
set start_re1 " in \\.?_start "
set start_re2 "\\.?_start \\(\\) at "
...
but there are no dwarf or elf symbols present.
Fix this by also allowing:
...
set start_re3 "$::hex in \\?\\? \\(\\) from "
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all
test programs. When running the testsuite in parallel mode, on
Cygwin, I noticed errors like:
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory
...
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory
...
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied
(Absolute paths elided above.)
The problem is that gdb_compile's unbuffered_mode_obj cache isn't
parallel safe. This is fixed in this commit.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2
|
|
Several tests assume that the first word after a thread ID in 'info
threads' output is "Thread". However, several targets use "LWP"
instead such as the FreeBSD and NetBSD native targets. The Linux
native target also uses "LWP" if libthread_db is not being used.
Targets that do not support threads use "process" as the first word
via normal_pid_to_str.
Add a tdlabel_re global variable as a regular-expression for a thread
label in `info threads' that matches either "process", "Thread", or
"LWP".
Some other tests in the tree don't require a specific word, and
some targets may use other first words (e.g. OpenBSD uses "thread"
and Ravenscar threads use "Ravenscar Thread").
|
|
On a system without ipv6 support enabled, when running test-case
gdb.server/server-connect.exp, it takes about 4 minutes, and I get:
...
builtin_spawn gdbserver --once ::1:2347 server-connect^M
Can't open socket: Address family not supported by protocol.^M
Exiting^M
PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
target remote tcp6:::1:2347^M
A program is being debugged already. Kill it? (y or n) y^M
could not connect: Address family not supported by protocol.^M
(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
...
Fix this by:
- recognizing the error message in gdbserver_start, and returning an empty list
to signal unsupported, and
- handling the unsupported response in the test-case.
This brings testing time down to 2 seconds, and gets me:
...
UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31502
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502
|
|
On aarch64-linux (debian 12), when running test-case
gdb.base/longjmp-until-in-main.exp, I run into:
...
(gdb) until 33^M
warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0xfff727c678928489^M
^M
0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main
...
This is PR gdb/26967: no longjmp probe is available:
...
(gdb) info probes stap libc ^longjmp$^M
No probes matched.^M
...
and glibc applies pointer mangling which makes it fairly difficult for gdb to
get the longjmp target.
There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit
b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp").
Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in
this and one more test-case.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When certain DAP tests are run in a certain order, dejagnu will throw
an exception during shutdown. After adding many logging statements, I
tracked this down to kill_wait_spawned_process not clearing the
'fileid' board_info entry, causing dejagnu to try to wait for the
process a second time -- and fail.
Tom de Vries then pointed out a second instance of this, which I
tracked down to the same problem occurring when spawning gdbserver.
This version of the patch fixes this by adding a new proc that can be
used to clean up board_info after waiting for a process to exit. I'm
not sure why this problem hasn't affected the test suite in the past.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31435
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This changes the DAP code to explicitly request that gdb exit.
Previously this could cause crashes, but with the previous cleanups,
this should no longer happen.
This also adds a tests that ensures that gdb exits with status 0.
|
|
The "python" command (and the Python implementation of the gdb
"source" command) does not handle Python exceptions in the same way as
other gdb-facing Python code. In particular, exceptions are turned
into a generic error rather than being routed through
gdbpy_handle_exception, which takes care of converting to 'quit' as
appropriate.
I think this was done this way because PyRun_SimpleFile and friends do
not propagate the Python exception -- they simply indicate that one
occurred.
This patch reimplements these functions to respect the general gdb
convention here. As a bonus, some Windows-specific code can be
removed, as can the _execute_file function.
The bulk of this change is tweaking the test suite to match the new
way that exceptions are displayed. These changes are largely
uninteresting. However, it's worth pointing out the py-error.exp
change. Here, the failure changes because the test changes the host
charset to something that isn't supported by Python. This then
results in a weird error in the new setup.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354
Acked-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Say we do:
...
$ make check RUNTESTFLAGS="gdb.dap/ada-nested.exp gdb.dap/pause.exp"
...
and add a perror at the end of pause.exp:
...
dap_shutdown
+
+perror "foo"
...
We run into:
...
UNRESOLVED: gdb.dap/ada-nested.exp: compilation prog.adb
...
This happens because the perror increases the errcnt, which is not reset at
the end of the test-case, and consequently the first pass in the following
test-case is changed into an unresolved.
Version 1.6.3 of dejagnu contains a fix which produces an unresolved at the
end of the test-case, which does reset the errcnt, but this is with version
1.6.1.
Furthermore, we reset the errcnt in clean_restart, but the pass is produced
before, so that doesn't help either.
Fix this by resetting errcnt and warncnt in default_gdb_init.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31351
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351
|
|
For a patch I submitted, the Linaro CI reported a failure:
...
FAIL: gdb.dap/attach.exp: exceptions in log file
...
I ran the test-case locally, and observed the same FAIL in the gdb.sum file.
I then wanted to confirm that I reproduced the exact same problem, but
realized that I couldn't because there's no way for me to know what exception
occurred, and where, because that information is logged in the dap.log.$n
file, and the Linaro CI only saves the gdb.sum and gdb.log files.
This issue is even worse if only the CI can reproduce a FAIL.
Fix this in dap_check_log_file by dumping dap.log.$n to gdb.log when
exceptions are found.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The output of "info breakpoints" includes breakpoint, watchpoint,
tracepoint, and catchpoint if they are created, so it should show
all the four types are deleted in the output of "info breakpoints"
to report empty list after "delete breakpoints".
It should also change the output of "delete breakpoints" to make it
clear that watchpoints, tracepoints, and catchpoints are also being
deleted. This is suggested by Guinevere Larsen, thank you.
$ make check-gdb TESTS="gdb.base/access-mem-running.exp"
$ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running
[...]
(gdb) break main
Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32.
(gdb) watch global_counter
Hardware watchpoint 2: global_counter
(gdb) trace maybe_stop_here
Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27.
(gdb) catch fork
Catchpoint 4 (fork)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32
2 hw watchpoint keep y global_counter
3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27
not installed on target
4 catchpoint keep y fork
Without this patch:
(gdb) delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) info breakpoints 3
No breakpoint or watchpoint matching '3'.
With this patch:
(gdb) delete breakpoints
Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y
(gdb) info breakpoints
No breakpoints, watchpoints, tracepoints, or catchpoints.
(gdb) info breakpoints 3
No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
In dap_gdb_start we do:
...
append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap"
...
While the dap log file setting comes before the dap interpreter setting,
the order is the other way around:
- first, the dap interpreter is started
- second, the -iex commands are executed and the log file is initialized.
Consequently, there's a race between dap interpreter startup and dap log file
initialization.
This cannot be fixed by using -eiex instead. Before the interpreter is
started, the "set debug dap-log-file" command is not yet registered.
Fix this by postponing the start of the DAP server until GDB has processed all
command files.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR dap/31386
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386
|
|
In _dap_read_json we have a gdb_expect with clauses that generate errors:
...
timeout {
error "timeout reading json header"
}
eof {
error "eof reading json header"
}
...
Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar
semantics related to errors:
...
# remote_expect works basically the same as standard expect, but it
# also takes care of getting the file descriptor from the specified
# host and also calling the timeout/eof/default section if there is an
# error on the expect call.
.....
When a timeout triggers, it generates a timeout error, which is reported by
gdb_expect, after which it runs the timeout/eof/default clauses, which
generates an eof error, which is reported by runtest.
I think the intention here is to generate just a one error, a timeout error.
Fix this by postponing generating the error until after gdb_expect.
Tested on x86_64-linux, by:
- running all the DAP test-cases and observing no regressions, and
- modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and
observing only a timeout error.
PR testsuite/31382
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31382
|
|
While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP
patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap
log file.
This is normally set up by dap_gdb_start, but the test-case doesn't use it.
Fix this by doing "set debug dap-log-file $logfile" in the test-case.
To make it easy to do so, I've factored out a new proc new_dap_log_file, and
while at likewise a new proc current_dap_log_file.
Note that the log file is currently empty.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Co-workers at AdaCore pointed out that gdb incorrectly implements the
DAP launch and configurationDone requests. It's somewhat strange to
me, but the spec does in fact say that configuration requests should
occur before the executable is known to gdb. This was clarified in
this bug report against the spec:
https://github.com/microsoft/debug-adapter-protocol/issues/452
Fixing 'launch' to start the inferior was straightforward, but this
then required some changes to how breakpoints are handled. In
particular, now gdb will emit the "pending" reason on a breakpoint,
and will suppress breakpoint events during breakpoint setting.
|
|
This changes the test suite to export dap_initialize.
|
|
On Fedora 39 aarch64 I run into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
relaying data between gdb and process 2114437^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib/ld-linux-aarch64.so.1...^M
_start () at ../sysdeps/aarch64/dl-start.S:22^M
warning: 22 ../sysdeps/aarch64/dl-start.S: No such file or directory^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
For contrast, on openSUSE Leap 15.4 x86_64 I have:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
relaying data between gdb and process 18797^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M
(gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
The fail happens in vgdb_start because the regexp only matches the
"in _start ()" variant, not the "_start () at":
...
gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"
...
Which variant you get is determined by presence of debug info.
Fix this by also matching the "_start () at" variant.
Tested aarch64-linux and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A user pointed out that gdb will print a Python exception when it gets
an EOF in DAP mode. And, it turns out that an EOF like this also
causes gdb not to exit. This is due to the refactoring that moved the
JSON reader to its own thread -- previously this caused an exception
to propagate and cause an exit, but now it just leaves the reader
hung.
This patch fixes these problems by arranging to handle EOF more
gracefully.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217
|
|
This rewrites the .debug_names reader to follow the spec.
Since it was first written, gdb's .debug_names writer has been
incorrect -- while the form of the section has been ok, the contents
have been very gdb-specific.
This patch fixes the reader side of this equation, rewriting the
reader to create a cooked index internally -- an important detail
because it allows for the deletion of a lot of code, and it means the
various readers will agree more often.
This reader checks for a new augmentation string. For the time being,
all other producers are ignored -- the old GDB ones because they are
wrong, and clang because it does not emit DW_IDX_parent. (If there
are any other producers, I'm unaware of them.)
While the new reader mostly runs in a worker thread, it does not try
to distribute its work. This could be done by partitioning the name
table. The parent computations could also be done in parallel after
all names have been read. I haven't attempted this.
Note that this patch temporarily regresses gdb.base/gdb-index-err.exp.
This test writes an index using gdb -- but at this particular stage,
gdb cannot read the indexes it creates. Rather than merge the patches
into a mega-patch, I've chosen to just accept this temporary
regression.
In v1 of this patch, I made the new reader more strict about requiring
.debug_aranges. In v2, I've backed this out and kept the previous
logic. This solved a few test failures, though it's arguably not the
right approach.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950
|
|
When running test-case gdb.mi/mi-dprintf.exp with check-read1, I run into:
...
(gdb) ^M
PASS: gdb.mi/mi-dprintf.exp: gdb: mi 2nd dprintf stop
-data-evaluate-expression stderr^M
^done,value="0x7ffff7e4a420 <_IO_2_1_stderr_>"^M
(gdb) FAIL: gdb.mi/mi-dprintf.exp: stderr symbol check
...
The problem is in proc mi_gdb_is_stderr_available:
...
proc mi_gdb_is_stderr_available {} {
set has_stderr_symbol false
gdb_test_multiple "-data-evaluate-expression stderr" "stderr symbol check" {
-re "\\^error,msg=\"'stderr' has unknown type; cast it to its declared type\"\r\n$::mi_gdb_prompt$" {
}
-re "$::mi_gdb_prompt$" {
set has_stderr_symbol true
}
}
...
which uses a gdb_test_multiple that is supposed to use the mi prompt, but
doesn't use -prompt to indicate this. Consequently, the default patterns use
the regular gdb prompt, which trigger earlier than the two custom patterns
which use "$::mi_gdb_prompt$".
Fix this by adding the missing -prompt "$::mi_gdb_prompt$" arguments.
While we're at it, make the gdb_test_multiple call a bit more readable by
using variables, and by using -wrap.
Tested on x86_64-linux, with:
- gcc and clang (to trigger both the has_stderr_symbol true and false cases)
- make check and make check-read1.
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
This patch contains work pulled from this previously proposed patch:
https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/
But has been modified by me. Credit for the original idea and
implementation goes to Lancelot, any bugs in this new iteration belong
to me.
Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is
empty other than the `foo' sub-directory, then currently within GDB,
if I type:
(gdb) file /tmp/f
and then hit TAB, GDB completes this to:
(gdb) file /tmp/foo/
notice that not only did GDB fill in the whole of `foo', but GDB also
added a trailing '/' character. This is done within readline when the
path that was just completed is a directory. However, if I instead
do:
(gdb) complete file /tmp/f
file /tmp/foo
I now see the completed directory name, but the trailing '/' is
missing. The reason is that, in this case, the completions are not
offered via readline, but are handled entirely within GDB, and so
readline never gets the chance to add the trailing '/' character.
The above patch added filename option support to GDB, which included
completion of the filename options. This initially suffered from the
same problem that I've outlined above, but the above patch proposed a
solution to this problem, but this solution only applied to filename
options (which have still not been added to GDB), and was mixed in
with the complete filename options support.
This patch pulls out just the fix for the trailing "/" problem, and
applies it to GDB's general filename completion. This patch does not
add filename options to GDB, that can always be done later, but I
think this small part is itself a useful fix.
One of the biggest changes I made in this version is that I got rid of
the set_from_readline member function, instead, I now pass the value
of m_from_readline into the completion_tracker constructor.
I then moved the addition of the trailing '/' into filename_completer
so that it is applied in the general filename completion case. I also
added a call to gdb_tilde_expand which was missing from the original
patch, I haven't tested, but I suspect that this meant that the
original patch would not add the trailing '/' if the user entered a
path starting with a tilde character.
When writing the test for this patch I ran into two problems.
The first was that the procedures in lib/completion-support.exp relied
on the command being completed for the test name. This is fine for
many commands, but not when completing a filename, if we use the
command in this case the test name will (potentially) include the name
of the directory in which the test is being run, which means we can't
compare results between two runs of GDB from different directories.
So in this commit I've gone through completion-support.exp and added a
new (optional) testname argument to many of the procedures, this
allows me to give a unique test name, that doesn't include the path
for my new tests.
The second issue was in the procedure make_tab_completion_list_re,
this builds the completion list which is displayed after a double tab
when there are multiple possible completions.
The procedure added the regexp ' +' after each completion, and then
added another ' +' at the very end of the expected output. So, if we
expected to match the name of two functions 'f1' and 'f2' the
generated regexp would be: 'f1 +f2 + +'. This would match just fine,
the actual output would be: 'f1 f2 ', notice that we get two spaces
after each function name.
However, if we complete two directory names 'd1' and 'd2' then the
output will be 'd1/ d2/ '. Notice that now we only have a single
space between each match, however, we do get the '/' added instead.
What happens is that when presenting the matches, readline always adds
the appropriate trailing character; if we performed tab completion of
'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with
a trailing space added. However, if we complete 'file d1' then we get
'file d1/'. Then readline is adding a single space after each
possible match, including the last one, which accounts for the
trailing space character.
To resolve this I've simply remove the addition o the second ' +'
within make_tab_completion_list_re, for the function completion
example I gave above the expected pattern is now 'f1 +f2 +', which for
the directory case we expect 'd1/ +d2/ +', both of which work just
fine.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265
Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
This patch adds two new options to gdb_compile to specify if the compile
should or should not generate the line table information. The
options are supported on clang and gcc version 7 and newer.
Patch has been tested on PowerPC with both gcc and clang.
|
|
This commit adds a mechanism for GDB to detect the linetable opcode
DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
that a certain instruction marks the point where the frame is destroyed.
While the standard allows for multiple points marked with epilogue_begin
in the same function, for performance reasons, the function that
searches for the epilogue address will only find the last address that
sets this flag for a given block.
This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
use the epilogue begin directly, and only if an epilogue can't be found
will it attempt heuristics based on the current instruction.
Finally, this commit also changes the dwarf assembler to be able to emit
epilogue-begin instructions, to make it easier to test this patch
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This changes the test suite to look for rogue DAP exceptions in the
log file, and issue a "fail" if one is found.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
In many cases, it's not possible for gdb to discover the executable
when a DAP 'attach' request is used. This patch lets the IDE supply
this information.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
While making recent changes to 'save gdb-index' command I triggered
some errors -- of the kind a user might be expected to trigger if they
do something wrong -- and I didn't find GDB's output as helpful as it
might be.
For example:
$ gdb -q /tmp/hello.x
...
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': mkstemp: No such file or directory.
That the error message mentions '/tmp/hello', which does exist, but
doesn't mention '/non_existing_dir', which doesn't is, I think,
confusing.
Also, I find the 'mkstemp' in the error message confusing for a user
facing error. A user might not know what mkstemp means, and even if
they do, that it appears in the error message is an internal GDB
detail. The user doesn't care what function failed, but wants to know
what was wrong with their input, and what they should do to fix
things.
Similarly, for a directory that does exist, but can't be written to:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': mkstemp: Permission denied.
In this case, the 'Permission denied' might make the user thing there
is a permissions issue with '/tmp/hello', which is not the case.
After this patch, the new errors are:
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory.
and:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied.
we also have:
(gdb) save gdb-index /tmp/not_a_directory
Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory.
I think these do a better job of guiding the user towards fixing the
problem.
I've added a new test that exercises all of these cases, and also
checks the case where a user tries to use an executable that already
contains an index in order to generate an index. As part of the new
test I've factored out some code from ensure_gdb_index (lib/gdb.exp)
into a new proc (get_index_type), which I've then used in the new
test. I've confirmed that all the tests that use ensure_gdb_index
still pass.
During review it was pointed out that the testsuite proc
have_index (lib/gdb.exp) is similar to the new get_index_type proc, so
I've rewritten have_index to also use get_index_type, I've confirmed
that all the tests that use have_index still pass.
Nothing that worked correctly before this patch should give an error
after this patch; I've only changed the output when the user was going
to get an error anyway.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This renames a couple of DAP procs in the testsuite, to clarify that
they are now exported. The cancellation test will need these.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
I noticed that the DWARF assembler starts abbrevs at 2.
I think 1 should be preferred.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
|
|
Commit 33ae45434d0 updated the text reported by GDB when showing the
number of worker threads. However, it neglected to update the assertions
using this text, which caused index-file.exp to fail. This commit
corrects this omission.
Tested index-file.exp is fixed on my local machine.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that after resizing to a narrow window, I got:
...
┌────────────────┐
│ │
│[ No Source Avail
able ] │
│ │
└────────────────┘
...
Fix this by adding two new functions:
- tui_win_info::display_string (int y, int x, const char *str)
- tui_win_info::display_string (const char *str)
that make sure that borders are not overwritten, which get us instead:
...
┌────────────────┐
│ │
│[ No Source Avai│
│ │
│ │
└────────────────┘
...
Tested on x86_64-linux.
|
|
The commit a3da2e7e550c4fe79128b5e532dbb90df4d4f418 has introduced
regressions when testing using the READ1 mechanism. The reason for that
is the new failure path in proc test_gdb_complete_tab_unique, which
looks for GDB suggesting more than what the test inputted, but not the
correct answer, followed by a white space. Consider the following case:
int foo(int bar, int baz);
Sending the command "break foo<tab>" to GDB will return
break foo(int, int)
which easily fits the buffer in normal testing, so everything works, but
when reading one character at a time, the test will find the partial
"break foo(int, " and assume that there was a mistake, so we get a
spurious FAIL.
That change was added because we wanted to avoid forcing a completion
failure to fail through timeout, which it had to do because there is no
way to verify that the output is done, mostly because when I was trying
to solve a different problem I kept getting reading errors and testing
completion was frustrating.
This commit implements a better way to avoid that frustration, by first
testing gdb's complete command and only if that passes we will test tab
completion. The difference is that when testing with the complete
command, we can tell when the output is over when we receive the GDB
prompt again, so we don't need to rely on timeouts. With this, the
change to test_gdb_complete_tab_unique has been removed as that test
will only be run and fail in the very unlikely scenario that tab
completion is different than command completion.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I spotted I made a small mistake in this commit:
commit aff250145af6c7a8ea9332bc1306c1219f4a63db
Date: Fri Nov 24 12:04:36 2023 +0000
gdb: generate gdb-index identically regardless of work thread count
In this commit I added a new proc in testsuite/lib/gdb.exp called
gdb_get_worker_threads. This proc uses gdb_test_multiple with two
possible patterns. One pattern is anchored with '^', while the other
is missing the '^' which it could use.
This commit adds the missing '^'.
|
|
It was observed that changing the number of worker threads that GDB
uses (maintenance set worker-threads NUM) would have an impact on the
layout of the generated gdb-index.
The cause seems to be how the CU are distributed between threads, and
then symbols that appear in multiple CU can be encountered earlier or
later depending on whether a particular CU moves between threads.
I certainly found this behaviour was reproducible when generating an
index for GDB itself, like:
gdb -q -nx -nh -batch \
-eiex 'maint set worker-threads NUM' \
-ex 'save gdb-index /tmp/'
And then setting different values for NUM will change the generated
index.
Now, the question is: does this matter?
I would like to suggest that yes, this does matter. At Red Hat we
generate a gdb-index as part of the build process, and we would
ideally like to have reproducible builds: for the same source,
compiled with the same tool-chain, we should get the exact same output
binary. And we do .... except for the index.
Now we could simply force GDB to only use a single worker thread when
we build the index, but, I don't think the idea of reproducible builds
is that strange, so I think we should ensure that our generated
indexes are always reproducible.
To achieve this, I propose that we add an extra step when building the
gdb-index file. After constructing the initial symbol hash table
contents, we will pull all the symbols out of the hash, sort them,
then re-insert them in sorted order. This will ensure that the
structure of the generated hash will remain consistent (given the same
set of symbols).
I've extended the existing index-file test to check that the generated
index doesn't change if we adjust the number of worker threads used.
Given that this test is already rather slow, I've only made one change
to the worker-thread count. Maybe this test should be changed to use
a smaller binary, which is quicker to load, and for which we could
then try many different worker thread counts.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Split out the code that makes a copy of the GDB executable ready for
self testing into a new proc. A later commit in this series wants to
load the GDB executable into GDB (for creating an on-disk debug
index), but doesn't need to make use of the full do_self_tests proc.
There should be no changes in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add new gdb.threads/step-over-thread-exit.exp and
gdb.threads/step-over-thread-exit-while-stop-all-threads.exp
testcases, exercising stepping over thread exit syscall. These make
use of lib/my-syscalls.S to define the exit syscall.
Co-authored-by: Pedro Alves <pedro@palves.net>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
Change-Id: Ie8b2c5747db99b7023463a897a8390d9e814a9c9
|
|
Refactor the syscall assembly code in gdb/testsuite/lib/my-syscalls.S
behind a SYSCALL macro so that it's easy to add new syscalls without
duplicating code.
Note that the way the macro is implemented, it only works correctly
for syscalls with up to 3 arguments, and, if the syscall doesn't
return (the macro doesn't bother to save/restore callee-saved
registers).
The following patch will want to use the macro to define a wrapper for
the "exit" syscall, so the limitations continue to be sufficient.
Change-Id: I8acf1463b11a084d6b4579aaffb49b5d0dea3bba
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
Functions of the hip runtime returning a hipError_t can be marked
nodiscard depending on the configuration[1] (when compiled with C++17).
This patch makes sure that we always check the value returned by
hipDeviceSynchronize and friends, and print an error message when
appropriate. This avoid a wall of warnings when running the testsuite
if the compiler defaults to using C++17.
It is always a good practice to check the return values anyway.
[1] https://github.com/ROCm-Developer-Tools/HIP/blob/docs/5.7.1/include/hip/hip_runtime_api.h#L203-L218
Change-Id: I2a819a8ac45f4bcf814efe9a2ff12c6a7ad22f97
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Simon pointed out that the new file-then-restart.exp test fails with
the extended-remote target board.
The problem is that the test suite doesn't use gdb_file_cmd -- which
handles things like "set remote exec-file". This patch changes
gdb_file_cmd to make the "kill" command optional, and then switches
the test case to use it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
