| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I spotted that the two functions:
record_full_open_1
record_full_core_open_1
both took two arguments, neither of which are used.
I stumbled onto this while reviewing how filename_completer is used.
The 'record full restore' command uses filename_completer and invokes
the cmd_record_full_restore function.
The cmd_record_full_restore function calls core_file_command and then
record_full_open, which then calls one of the above functions.
As 'record full restore' takes a filename, this is passed to
cmd_record_full_restore, which forwards the filename to both
core_file_command and record_full_open. However, record_full_open
never actually uses the filename that is passed in.
The record_full_open function is also used for 'target record-full'.
I propose that record_full_open should no longer expect to see any
user supplied arguments passed in (it doesn't use any). In fact, I've
added a check that if we do get any user supplied arguments we'll
throw an error.
Now that we know record_full_open isn't being passed any user
arguments we can stop passing the arguments to record_full_open_1 and
record_full_core_open_1, this will make no user visible difference as
these arguments were not used.
It is possible that a user was previously doing:
(gdb) target record-full blah blah blah
And this previously would work fine, the 'blah blah blah' was
ignored. Now this will give an error. Other than this case there
should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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
|
|
I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main:
...
00000000004102c4 <end_of_sequence>:
4102c4: 52800000 mov w0, #0x0 // #0
4102c8: 9100c3ff add sp, sp, #0x30
4102cc: d65f03c0 ret
...
is not described by the line table:
...
File name Line number Starting address View Stmt
...
map-to-same-line.c 54 0x4102ac x
map-to-same-line.c - 0x4102c4
...
Fix this by ending the line table at $main_end.
Likewise in a few other test-cases, found using:
...
$ find gdb/testsuite/ -type f \
| xargs grep -B1 DW_LNE_end_sequence \
| grep set_address \
| egrep -v "_end|_len"
...
Tested on aarch64-linux.
|
|
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
|
|
In AIX, if in the main program the global variables are unused then the linker optimises
these variables and the dwarf will not have proper address to the same. Hence we cannot access these
variables.
This patch is a fix to the same so that all the test case of max-depth can passs in AIX as well.
|
|
The commit ed32754a8c7 ("[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for
remote target") intended to addresss the problem that this command:
...
set gdbserver_pid [exp_pid -i $server_spawn_id]
...
does not return the pid of the gdbserver for remote target, but rather the one
of the ssh client session.
To fix this, it added another way of getting the gdbserver_pid.
For the trivial case of non-remote target, the PID found by either method
should be identical, but if we compare those by adding
"puts [exec ps -p $gdbserver_pid]" we get:
...
PID TTY TIME CMD
31711 pts/8 00:00:00 gdbserver
PID TTY TIME CMD
31718 pts/8 00:00:00 server-kill-pyt
...
The problem is that while the gdbserver PID is supposed to be read from the
result of "gdb.execute ('p server_pid')" in the python script, instead it's
taken from:
...
Process server-kill-python created; pid = 31718^M
...
Fix this by moving the printing of the gdbserver PID out of the python script.
Also double-check the two methods against each other, in the cases that they
should match.
Tested on x86_64-linux.
PR testsuite/31633
https://sourceware.org/bugzilla/show_bug.cgi?id=31633
|
|
In test-case gdb.server/server-kill-python.exp we have:
...
if {[gdb_spawn_with_cmdline_opts \
"-quiet -iex \"set height 0\" -iex \"set width 0\" -ex \"source $host_file1\""] != 0} {
fail "spawn"
return
}
...
I reproduced the problem by reverting the fix at the commit adding both the
fix and the test-case, and the reproduced the same problem using:
...
(gdb) source $host_file1
...
so there doesn't seem to be a specific need to source the python file using
"-ex".
Simplify the test-case by sourcing the python file using send_gdb.
This also allow us to simplify the python script.
Tested on x86_64-linux.
|
|
Add another regression test for PR symtab/30846.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846
|
|
Add a regression test for PR symtab/30846.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846
|
|
PR python/31631 reports a gdb internal error when doing:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)
utils.c:709: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
Fix this by throwing a python MemoryError, such that we have instead:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)
Python Exception <class 'MemoryError'>:
Error occurred in Python.
(gdb)
...
Likewise for DAP.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631
|
|
A co-worker noticed a strange situation where "target remote" would
fail due to a trailing newline in the address part of the command.
Eventually he tracked this down to the fact that he was pasting the
command into the terminal, and due to bracketed paste mode, the
newline was being preserved by readline.
It seems to me that we basically never want a trailing newline on a
gdb command, so this patch removes it when handling the readline
result.
Co-Authored-By: Kévin Le Gouguec <legouguec@adacore.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
Currently, when the current thread is running, you can print global
variables. However, if you try to set a watchpoint on the same
globals, GDB errors out, complaining that the selected thread is
running. Like so:
(gdb) c&
Continuing.
(gdb) p global
$1 = 1098377287
(gdb) watch global
Selected thread is running.
This patch makes setting the watchpoint work. You'll now get:
(gdb) c&
Continuing.
(gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)]
[New Thread 0x7ffff756d640 (LWP 434994)]
p global
$1 = 88168
(gdb) watch global
Hardware watchpoint 2: global
(gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)]
Thread 2 "function0" hit Hardware watchpoint 2: global
Old value = 185420
New value = 185423
int_return () at threads.c:39
39 }
The problem is that update_watchpoint calls get_selected_frame
unconditionally. We can skip it if the watchpoint expression is only
watching globals.
This adds a testcase that exercises both all-stop and non-stop, and
also software and hardware watchpoints. It is kfailed for software
watchpoints, as those require another fix not handled by this patch
(the sw watchpoint doesn't fire because GDB doesn't force the
running-free thread to switch to single-stepping).
Change-Id: I68ca948541aea3edd4f70741f272f543187abe40
|
|
Add a new testcase for exercising attaching to a process after its
main thread has exited.
This is not possible on Linux, the kernel does not allow attaching to
a zombie task, so the test is kfailed there. It is possible however
on Windows at least, and was the scenario addressed by the Windows
backend fix in
https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html,
nowadays PR threads/8153, back in 2003.
Passes cleanly on Cygwin.
KFAILed on GNU/Linux native and gdbserver.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555
Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b
|
|
On Cygwin, the gdb.base/fork-no-detach-follow-child-dlopen.exp
testcase hits a sequence of cascading FAILs:
(gdb) run
Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
[New Thread 12672.0x318c]
[New Thread 12672.0x2844]
[New Thread 12672.0x714]
FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: runto: run to add (timeout)
frame
FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: frame (timeout)
list
FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: list (timeout)
And the test program never makes progress.
... and at this point, Cygwin is completely stuck. I can't run any
other Cygwin program.
However, if we run the test program outside DejaGnu, we see something
different:
(gdb) b add
Function "add" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (add) pending.
(gdb) r
Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
[New Thread 10968.0x834]
[New Thread 10968.0x29a4]
[New Thread 10968.0x16b8]
[New Thread 10968.0xf9c]
[Switching to Thread 10968.0x16b8]
Thread 4 "sig" hit Breakpoint 1.2, pending_signals::add (pack=..., this=0x7ffa1e748a40 <sigq>) at /usr/src/debug/cygwin-3.4.9-1/winsup/cygwin/sigproc.cc:1304
1304 se = sigs + pack.si.si_signo;
(gdb)
Ah, the test wanted to run to a global "add" function, but managed to
stop at an internal Cygwin method called "add". And stopping there
deadlocks everything Cygwin in the system. (I believe some
cygwin1.dll mechanisms use cross-process synchronization or
communication, we're probably blocking something like that.)
Fix this by using "break -q". The tests FAIL because we don't support
follow-fork for Cygwin, but at least we no longer deadlock the
machine.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I7181d8481c2ae1024b0d73e3bb194f9a4f0a7eb9
|
|
When running test-case gdb.threads/access-mem-running-thread-exit.exp with
clang, we run into:
...
(gdb) print global_var = 555^M
No symbol "global_var" in current context.^M
(gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: all-stop: \
access mem (write to global_var, inf=2, iter=1)
...
The problem is that clang removes the unused variable.
Fix this in the same way as done in commit b4f767131f7
("Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC"), by incrementing the
variable.
Tested on x86_64-linux with gcc and clang.
|
|
For some reason install-dvi is missing although other targets of the
same family are present. This looks like an oversight.
This enables calling 'make install-dvi' from the top-level build
directory.
Fix what looks like another oversight: include 'pdf' in 'all-doc' in
gdb/doc/Makefile.in.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
When the XML support was disabled at compile time,
the test case gdb.threads/stepi-over-clone.exp fails
with lots of time-outs, which can be annoying.
This makes the test case unsupported instead.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names. However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low. The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).
This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276
libiberty
* cplus-dem.c (cplus_demangle): Try the D demangler with
"auto" format.
* testsuite/d-demangle-expected: Add --format=auto test.
|
|
The recent change to how unsized Rust values are printed included a
small regression from past behavior. Previously, a slice's type would
be printed, like:
(gdb) print slice
$80 = &[i32] [3]
The patch changed this to just
(gdb) print slice
$80 = [3]
This patch restores the previous behavior.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31517
|
|
Ada 2022 includes iterated assignment for array initialization. This
patch implements a subset of this for gdb. In particular, only arrays
with integer index types really work -- currently there's no decent
way to get the index type in EVAL_AVOID_SIDE_EFFECTS mode during
parsing. Fixing this probably requires the Ada parser to take a
somewhat more sophisticated approach to type resolution; and while
this would help fix another bug in this area, this patch is already
useful without it.
|
|
This patch is the result of running 'isort .' in the gdb directory.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
On fedora rawhide, when running test-case gdb.base/ctf-ptype.exp, I get:
...
gdb compile failed, ctf-ptype.c: In function 'main':
ctf-ptype.c:242:29: error: implicit declaration of function 'malloc' \
[-Wimplicit-function-declaration]
242 | v_char_pointer = (char *) malloc (1);
| ^~~~~~
ctf-ptype.c:1:1: note: include '<stdlib.h>' or provide a declaration of 'malloc'
+++ |+#include <stdlib.h>
1 | /* This test program is part of GDB, the GNU debugger.
...
Fix this by adding the missing include.
Tested on aarch64-linux.
|
|
In an aarch32-linux chroot on an aarch64-linux system, I run into:
...
(gdb) print x^M
$1 = 9223372036854775807^M
(gdb) FAIL: gdb.ada/verylong.exp: print x
...
A passing version on aarch64-linux looks like:
...
(gdb) print x^M
$1 = 170141183460469231731687303715884105727^M
(gdb) PASS: gdb.ada/verylong.exp: print x
...
The difference is caused by the size of the type Long_Long_Long_Integer, which
is:
- a 128-bit signed on 64-bit targets, and
- a 64-bit signed on 32-bit target.
Fix this by detecting the size of the Long_Long_Long_Integer type, and
handling it.
Tested on aarch64-linux and aarch32-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31574
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31574
[1] https://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html
|
|
After starting TUI like this with a hello world a.out:
...
$ gdb -q a.out -ex start -ex "tui enable"
...
we get:
...
┌─hello.c──────────────────────────────┐
│ 5 { │
│ 6 printf ("hello\n"); │
│ 7 │
│ 8 return 0; │
│ 9 } │
│ │
└──────────────────────────────────────┘
...
This is a regression since commit ee1e9bbb513 ("[gdb/tui] Fix displaying main
after resizing"), before which we had instead:
...
┌─hello.c──────────────────────────────┐
│ 4 main (void) │
│ 5 { │
│ > 6 [7m printf ("hello\n");[0m │
│ 7 │
│ 8 return 0; │
│ 9 } │
└──────────────────────────────────────┘
...
In other words, the problems are:
- the active line (source line 6) is no longer highlighted, and
- the active line is not vertically centered (screen line 2 out 6 instead of
screen line 3 out of 6).
Fix these problems respectively by:
- in tui_enable, instead of "tui_show_frame_info (0)" using
'tui_show_frame_info (deprecated_safe_get_selected_frame ())", and
- in tui_source_window_base::rerender, adding centering functionality.
Tested on aarch64-linux.
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/31522
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31522
|
|
The gdb.python/py-cmd-prompt.exp script includes a test that has a
gdbserver port number within a test name. As port numbers can change
from one test run to the next (depending on what else is running on
the machine at the time), this can make it hard to compare test
results between runs.
Give the test a specific name to avoid including the port number.
There is no change in what is tested after this commit.
|
|
Provide an explicit name for a test in gdb.base/pc-not-saved.exp to
avoid printing $pc and $sp values in the test name -- these values
might change between different test runs, which makes it harder to
compare test results.
There is no change in what is actually being tested with this commit.
|
|
On fedora rawhide, with test-case gdb.trace/collection.exp, I get:
...
gdb compile failed, collection.c: In function 'strings_test_func':
collection.c:227:13: error: implicit declaration of function 'malloc' \
[-Wimplicit-function-declaration]
227 | longloc = malloc(500);
| ^~~~~~
collection.c:1:1: note: \
include '<stdlib.h>' or provide a declaration of 'malloc'
+++ |+#include <stdlib.h>
1 | /* This testcase is part of GDB, the GNU debugger.
collection.c:228:3: error: implicit declaration of function 'strcpy' \
[-Wimplicit-function-declaration]
228 | strcpy(longloc, ... );
| ^~~~~~
collection.c:1:1: note: include '<string.h>' or provide a declaration of \
'strcpy'
+++ |+#include <string.h>
1 | /* This testcase is part of GDB, the GNU debugger.
collection.c:230:8: error: implicit declaration of function 'strlen' \
[-Wimplicit-function-declaration]
230 | i += strlen (locstr);
| ^~~~~~
collection.c:230:8: note: include '<string.h>' or provide a declaration of \
'strlen'
...
Fix this by adding the missing includes.
Tested on aarch64-linux.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
On fedora rawhide, when running test-case gdb.linespec/break-asm-file.exp, I
get:
...
gdb compile failed, break-asm-file.c:21:8: error: \
return type defaults to 'int' [-Wimplicit-int]
21 | static func()
| ^~~~
...
Fix this by adding the missing return type.
Tested on aarch64-linux.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
On aarch64-linux, using the manjaro linux distro, I run into:
...
(gdb) next^M
32 }^M
(gdb) next^M
0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M
(gdb) FAIL: gdb.base/ending-run.exp: step out of main
...
What happens here is described in detail in this clause:
...
-re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" {
# This case occurs on Powerpc when gdb steps out of main and the
# needed debug info files are not loaded on the system, preventing
# GDB to determine which function it reached (__libc_start_call_main).
# Ideally, the target system would have the necessary debugging
# information, but in its absence, GDB's behavior is as expected.
...
}
...
but the clause only matches for powerpc.
Fix this by:
- making the regexp generic enough to also match /usr/lib/libc.so.6, and
- updating the comment to not mention powerpc.
Tested on aarch64-linux.
PR testsuite/31450
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450
|
|
When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using
the manjaro linux distro, I get:
...
(gdb) thread apply all bt^M
^M
Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M
#0 0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M
#1 0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M
#2 0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M
#3 0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M
#4 0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M
#5 0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M
^M
Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M
#0 0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M
#1 0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M
#2 0x0000aaaade37086c in main () at attach-stopped.c:45^M
(gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt
...
The problem is that the test-case expects to see start_thread:
...
gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \
"$threadtype: attach2 to stopped bt"
...
but lack of symbols makes that impossible.
Fix this by allowing " in ?? () from " as well.
Tested on aarch64-linux.
PR testsuite/31451
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451
|
|
On fedora rawhide, with test-case gdb.base/rtld-step.exp I get:
...
static-pie-static-libc.c: In function '_start':^M
static-pie-static-libc.c:1:22: error: \
implicit declaration of function '_exit' [-Wimplicit-function-declaration]^M
1 | void _start (void) { _exit (0); }^M
| ^~~~~^M
compiler exited with status 1
...
UNTESTED: gdb.base/rtld-step.exp: failed to compile \
(-static-pie not supported or static libc missing)
...
Fix this by adding the missing include.
Tested on aarch64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
A user on irc pointed out that parse_number.exp has a redundant check.
This patch removes the duplicate.
|
|
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
|
|
Currently GDB only supports using single quotes for quoting things,
the reason for this, as explained in completer.c (next to the variable
gdb_completer_expression_quote_characters) is that double quoted
strings need to be treated differently by the C expression parser.
But for filenames I don't believe this restriction holds. The file
names as passed to things like the 'file' command are not passing
through the C expression parser, so it seems like we should be fine to
allow double quotes for quoting in this case.
And so, this commit extends GDB to allow double quotes for quoting
filenames. Maybe in future we might be able to allow double quote
quoting in additional places, but this seems enough for now.
The testing has been extended to cover double quotes in addition to
the existing single quote testing.
This change does a number of things:
1. Set rl_completer_quote_characters in filename_completer and
filename_completer_handle_brkchars, this overrides the default which
is set in complete_line_internal_1,
2. In advance_to_completion_word we now take a set of quote
characters as a parameter, the two callers
advance_to_expression_complete_word_point and
advance_to_filename_complete_word_point now pass in the required set
of quote characters,
3. In completion_find_completion_word we now use the currently active
set of quote characters, this means we'll use
gdb_completer_expression_quote_characters or
gdb_completer_file_name_quote_characters depending on what type of
things we are completing.
|
|
In gdb_completion_word_break_characters_throw, after calling
complete_line_internal, if the completion function chose to use a
custom word point then we set rl_completer_quote_characters to NULL.
However, nowhere do we set rl_completer_quote_characters back to its
default value, which is setup in init_main (top.c).
An example of something that uses a custom word point for its
completion is 'thread apply all ...'.
An example of something that relies on rl_completer_quote_characters
would be completion of a quoted filename that contains white space.
Consider this shell and GDB session. The <TAB> markers indicate where
I've used tab to trigger completion:
$ mkdir /tmp/aaa\ bbb
$ touch /tmp/aaa\ bbb/xx\ 11
$ touch /tmp/aaa\ bbb/xx\ 22
$ gdb -q
(gdb) file '/tmp/aaa bbb/xx<TAB><TAB>
xx 11 xx 22
(gdb) thread apply all hel<TAB>
(gdb) thread apply all help
(gdb) file '/tmp/aaa bbb/xx<TAB><TAB>
First I create a directory structure which uses white space within
file and directory names. Then within GDB I use the 'file' command
and use a single quote to quote the filename. When I tab complete GDB
correctly offers the two files within the directory '/tmp/aaa bbb/'.
This works because rl_completer_quote_characters contains the single
quote, and so readline knows that it is trying to complete the string
that starts after the single quote: /tmp/aaa bbb/xx
Next I invoke the completer for the 'thread apply all' command, to do
this I type 'thread apply all hel' and hit tab, this expands to the
one completion 'thread apply all help'. We can run this command or
not, it doesn't matter (there are no threads, so we'll get no output).
Now I repeat the original 'file' completion. This time though I don't
get offered any completions.
The reason is that the 'thread apply all' completer set
rl_completer_quote_characters to nullptr. Now, when readline tries to
figure out the word to complete it doesn't see the single quote as the
start of a quoted word, so instead readline falls back to the word
break characters, and in this case spots the white space. As a result
readline tries to complete the string 'bbb/xx' which obviously doesn't
have any completions.
By setting rl_completer_quote_characters each time completion is
invoked this problem is resolved and the second 'file' command
completes as expected.
I've extended gdb.base/filename-completion.exp to also test with
quoted filenames, and added a 'thread apply all' completion at the
start to expose this bug.
As setting of rl_completer_quote_characters is now all done in the
completer.c file the function get_gdb_completer_quote_characters()
could be made static. However, as this function is only used one time
to initialise rl_completer_quote_characters, I've instead just deleted
get_gdb_completer_quote_characters() and used
gdb_completer_quote_characters directly.
|
|
We now have unwind-on-timeout and unwind-on-terminating-exception, and
then the odd one out unwindonsignal.
I'm not a great fan of these squashed together command names, so in
this commit I propose renaming this to unwind-on-signal.
Obviously I've added the hidden alias unwindonsignal so any existing
GDB scripts will keep working.
There's one test that I've extended to test the alias works, but in
most of the other test scripts I've changed over to use the new name.
The docs are updated to reference the new name.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>
|
|
Now that inferior function calls can timeout (see the recent
introduction of direct-call-timeout and indirect-call-timeout), this
commit adds a new setting unwind-on-timeout.
This new setting is just like the existing unwindonsignal and
unwind-on-terminating-exception, but the new setting will cause GDB to
unwind the stack if an inferior function call times out.
The existing inferior function call timeout tests have been updated to
cover the new setting.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>
|
|
In the previous commits I have been working on improving inferior
function call support. One thing that worries me about using inferior
function calls from a conditional breakpoint is: what happens if the
inferior function call fails?
If the failure is obvious, e.g. the thread performing the call
crashes, or hits a breakpoint, then this case is already well handled,
and the error is reported to the user.
But what if the thread performing the inferior call just deadlocks?
If the user made the call from a 'print' or 'call' command, then the
user might have some expectation of when the function call should
complete, and, when this time limit is exceeded, the user
will (hopefully) interrupt GDB and regain control of the debug
session.
But, when the inferior function call is from a breakpoint condition it
is much harder to understand that GDB is deadlocked within an inferior
call. Maybe the breakpoint hasn't been hit yet? Or maybe the
condition was always false? Or maybe GDB is deadlocked in an inferior
call? The only way to know for sure is for the user to periodically
interrupt the inferior, check on the state of all the threads, and
then continue.
Additionally, the focus of the previous commit was inferior function
calls, from a conditional breakpoint, in a multi-threaded inferior.
This opens up a whole new set of potential failure conditions. For
example, what if the function called relies on interaction with some
other thread, and the other thread crashes? Or hits a breakpoint?
Given how inferior function calls work (in a synchronous manner), a
stop event in some other thread is going to be ignored while the
inferior function call is being executed as part of a breakpoint
condition, and this means that GDB could get stuck waiting for the
original condition thread, which will now never complete.
In this commit I propose a solution to this problem. A timeout. For
targets that support async-mode we can install an event-loop timer
before starting the inferior function call. When the timer expires we
will stop the thread performing the inferior function call. With this
mechanism in place a user can be sure that any inferior call they make
will either complete, or timeout eventually.
Adding a timer like this is obviously a change in behaviour for the
more common 'call' and 'print' uses of inferior function calls, so, in
this patch, I propose having two different timers. One I call the
'direct-call-timeout', which is used for 'call' and 'print' commands.
This timeout is by default set to unlimited, which, not surprisingly,
means there is no timeout in place.
A second timer, which I've called 'indirect-call-timeout', is used for
inferior function calls from breakpoint conditions. This timeout has
a default value of 30 seconds. This is a reasonably long time to
wait, and hopefully should be enough in most cases to allow the
inferior call to complete. An inferior call that takes more than 30
seconds, which is installed on a breakpoint condition is really going
to slow down the debug session, so hopefully this is not a common use
case.
The user is, of course, free to reduce, or increase the timeout value,
and can always use Ctrl-c to interrupt an inferior function call, but
this timeout will ensure that GDB will stop at some point.
The new commands added by this commit are:
set direct-call-timeout SECONDS
show direct-call-timeout
set indirect-call-timeout SECONDS
show indirect-call-timeout
These new timeouts do depend on async-mode, so, if async-mode is
disabled (maint set target-async off), or not supported (e.g. target
sim), then the timeout is treated as unlimited (that is, no timeout is
set).
For targets that "fake" non-async mode, e.g. Linux native, where
non-async mode is really just async mode, but then we park the target
in a sissuspend, we could easily fix things so that the timeouts still
work, however, for targets that really are not async aware, like the
simulator, fixing things so that timeouts work correctly would be a
much bigger task - that effort would be better spent just making the
target async-aware. And so, I'm happy for now that this feature will
only work on async targets.
The two new show commands will display slightly different text if the
current target is a non-async target, which should allow users to
understand what's going on.
There's a somewhat random test adjustment needed in gdb.base/help.exp,
the test uses a regexp with the apropos command, and expects to find a
single result. Turns out the new settings I added also matched the
regexp, which broke the test. I've updated the regexp a little to
exclude my new settings.
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>
|
|
This commit fixes bug PR 28942, that is, creating a conditional
breakpoint in a multi-threaded inferior, where the breakpoint
condition includes an inferior function call.
Currently, when a user tries to create such a breakpoint, then GDB
will fail with:
(gdb) break infcall-from-bp-cond-single.c:61 if (return_true ())
Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61.
(gdb) continue
Continuing.
[New Thread 0x7ffff7c5d700 (LWP 2460150)]
[New Thread 0x7ffff745c700 (LWP 2460151)]
[New Thread 0x7ffff6c5b700 (LWP 2460152)]
[New Thread 0x7ffff645a700 (LWP 2460153)]
[New Thread 0x7ffff5c59700 (LWP 2460154)]
Error in testing breakpoint condition:
Couldn't get registers: No such process.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(return_true) will be abandoned.
When the function is done executing, GDB will silently stop.
Selected thread is running.
(gdb)
Or, in some cases, like this:
(gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1))
Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56.
(gdb) continue
Continuing.
[New Thread 0x7ffff7c5d700 (LWP 2461106)]
[New Thread 0x7ffff745c700 (LWP 2461107)]
../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The precise error depends on the exact thread state; so there's race
conditions depending on which threads have fully started, and which
have not. But the underlying problem is always the same; when GDB
tries to execute the inferior function call from within the breakpoint
condition, GDB will, incorrectly, try to resume threads that are
already running - GDB doesn't realise that some threads might already
be running.
The solution proposed in this patch requires an additional member
variable thread_info::in_cond_eval. This flag is set to true (in
breakpoint.c) when GDB is evaluating a breakpoint condition.
In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is
true, then GDB will only try to resume the current thread, that is,
the thread for which the breakpoint condition is being evaluated.
This solves the problem of GDB trying to resume threads that are
already running.
The next problem is that inferior function calls are assumed to be
synchronous, that is, GDB doesn't expect to start an inferior function
call in thread #1, then receive a stop from thread #2 for some other,
unrelated reason. To prevent GDB responding to an event from another
thread, we update fetch_inferior_event and do_target_wait in infrun.c,
so that, when an inferior function call (on behalf of a breakpoint
condition) is in progress, we only wait for events from the current
thread (the one evaluating the condition).
In do_target_wait I had to change the inferior_matches lambda
function, which is used to select which inferior to wait on.
Previously the logic was this:
auto inferior_matches = [&wait_ptid] (inferior *inf)
{
return (inf->process_target () != nullptr
&& ptid_t (inf->pid).matches (wait_ptid));
};
This compares the pid of the inferior against the complete ptid we
want to wait on. Before this commit wait_ptid was only ever
minus_one_ptid (which is special, and means any process), and so every
inferior would match.
After this commit though wait_ptid might represent a specific thread
in a specific inferior. If we compare the pid of the inferior to a
specific ptid then these will not match. The fix is to compare
against the pid extracted from the wait_ptid, not against the complete
wait_ptid itself.
In fetch_inferior_event, after receiving the event, we only want to
stop all the other threads, and call inferior_event_handler with
INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint.
If we are, then all the other threads should be left doing whatever
they were before. The inferior_event_handler call will be performed
once the breakpoint condition has finished being evaluated, and GDB
decides to stop or not.
The final problem that needs solving relates to GDB's commit-resume
mechanism, which allows GDB to collect resume requests into a single
packet in order to reduce traffic to a remote target.
The problem is that the commit-resume mechanism will not send any
resume requests for an inferior if there are already events pending on
the GDB side.
Imagine an inferior with two threads. Both threads hit a breakpoint,
maybe the same conditional breakpoint. At this point there are two
pending events, one for each thread.
GDB selects one of the events and spots that this is a conditional
breakpoint, GDB evaluates the condition.
The condition includes an inferior function call, so GDB sets up for
the call and resumes the one thread, the resume request is added to
the commit-resume queue.
When the commit-resume queue is committed GDB sees that there is a
pending event from another thread, and so doesn't send any resume
requests to the actual target, GDB is assuming that when we wait we
will select the event from the other thread.
However, as this is an inferior function call for a condition
evaluation, we will not select the event from the other thread, we
only care about events from the thread that is evaluating the
condition - and the resume for this thread was never sent to the
target.
And so, GDB hangs, waiting for an event from a thread that was never
fully resumed.
To fix this issue I have added the concept of "forcing" the
commit-resume queue. When enabling commit resume, if the force flag
is true, then any resumes will be committed to the target, even if
there are other threads with pending events.
A note on authorship: this patch was based on some work done by
Natalia Saiapova and Tankut Baris Aktemur from Intel[1]. I have made
some changes to their work in this version.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28942
[1] https://sourceware.org/pipermail/gdb-patches/2020-October/172454.html
Co-authored-by: Natalia Saiapova <natalia.saiapova@intel.com>
Co-authored-by: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>
|
|
With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc
12, I get:
...
(gdb) set debug symtab-create 1^M
(gdb) print *the_local_var^M
...
$1 = (n => 2)^M
(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
...
The problem is that this fails:
...
-re -wrap ".* = \\\(n => $decimal\\\)" {
if {$found_pck + $found_pck2 == 1} {
pass $gdb_test_name
} else {
fail $gdb_test_name
}
...
because $found_pck == 0 and $found_pck2 == 0.
Indeed, with gcc 13 we have:
...
$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
b~foo.adb
b~foo.adb
b~foo.adb
b~foo.ads
pck2.adb
pck2.adb
pck2.ads
pck2.adb
pck2.ads
...
and with gcc 12:
...
$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
b~foo.adb
b~foo.adb
b~foo.adb
b~foo.ads
...
Fix this by checking for "$found_pck + $found_pck2 <= 1" instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31514
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514
|
|
Commit 467a34bb9e6 ("gdb tests: Allow for "LWP" or "process" in thread IDs
from info threads") introduces a new global variable tdlabel_re, but fails to
indicate it's global when used in procs in four test-cases.
Fix this by adding "global tdlabel_re".
Tested on aarch64-linux.
|
|
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").
|
|
This commit teaches GDB's gcore command to generate sparse core files
(if supported by the filesystem).
To create a sparse file, all you have to do is skip writing zeros to
the file, instead lseek'ing-ahead over them.
The sparse logic is applied when writing the memory sections, as
that's where the bulk of the data and the zeros are.
The commit also tweaks gdb.base/bigcore.exp to make it exercise
gdb-generated cores in addition to kernel-generated cores. We
couldn't do that before, because GDB's gcore on that test's program
would generate a multi-GB non-sparse core (16GB on my system).
After this commit, gdb.base/bigcore.exp generates, when testing with
GDB's gcore, a much smaller core file, roughly in line with what the
kernel produces:
real sizes:
$ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
2.2M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
2.0M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel
apparent sizes:
$ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel
Time to generate the core also goes down significantly. On my machine, I get:
when writing to an SSD, from 21.0s, down to 8.0s
when writing to an HDD, from 31.0s, down to 8.5s
The changes to gdb.base/bigcore.exp are smaller than they look at
first sight. It's basically mostly refactoring -- moving most of the
code to a new procedure which takes as argument who should dump the
core, and then calling the procedure twice. I purposely did not
modernize any of the refactored code in this patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1
|
|
Ada 2022 includes a "delta aggregates" feature that can sometimes
simplify aggregate creation. This patch implements this feature for
GDB.
|
|
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/corefile-buildid.exp, I get:
...
expecting exec file "debugdir-exec/.build-id/ec/f10ec5d39648774f8c35d3cf757c8db52f5163"
info files^M
Local core dump file:^M
`build-exec/corefile-buildid.core', file type elf64-littleaarch64.^M
0x0000aaaac1d70000 - 0x0000aaaac1d71000 is load1^M
...
0x0000ffffffa8b000 - 0x0000ffffffaac000 is load16^M
(gdb) FAIL: gdb.base/corefile-buildid.exp: exec: info files
...
The problem is that the test-case expect the build-id to be available in the
core file, while it isn't.
Fix this by detecting that the build-id isn't available in the core file using eu-readelf, as in
gdb.base/coredump-filter-build-id.exp.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
It's currently not possible to cast an in-memory value of a primitive
type to const reference:
```
(gdb) p Q.id
$1 = 42
(gdb) p (int&)Q.id
$2 = (int &) @0x22fd0c: 42
(gdb) p (const int&)Q.id
Attempt to take address of value not located in memory.
```
And if in a function call an argument needs the same kind of casting,
it also doesn't work:
```
(gdb) l f3
39 int f3(const int &i)
40 {
41 return i;
42 }
(gdb) p f3(Q.id)
Attempt to take address of value not located in memory.
```
It's because when the constness of the type changes in a call to
value_cast, a new not_lval value is allocated, which doesn't exist
in the target memory.
Fixed by ignoring const/volatile/restrict qualifications in
value_cast when comparing cast type to original type, so the new
value will point to the same location as the original value:
```
(gdb) p (int&)i
$2 = (int &) @0x39f72c: 1
(gdb) p (const int&)i
$3 = (const int &) @0x39f72c: 1
(gdb) p f3(Q.id)
$4 = 42
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423
Approved-By: Tom Tromey <tom@tromey.com>
|
