| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
add support to recording 2 missing AVX instructions: vaddsubps and vaddsubpd, and add associated tests.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
A recent patch of mine modified wchar.exp, but I failed to notice one
part of the review. This patch updates the code to conform to the
review comments.
|
|
Hannes filed a bug that pointed out that:
print L'\\'
... did not work correctly. The bug is in convert_escape, which
simply transcribes the backslash character, rather than convert it
between encodings.
This patch fixes the error. I also turned a macro into a lambda to
clean up this code a little.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33124
Reviewed-By: Tom de Vries <tdevries@suse.de>
Tested-By: Hannes Domani <ssbssa@yahoo.de>
|
|
Use the contrib/dg-extract-results.sh script to create a gdb.sum and
gdb.log summary after running the check-all-boards make target.
Having the results from all the boards merged into a single file
isn't (maybe) the most useful, but it isn't a bad thing. However, the
great thing about merge the results is that the totals are also
merged.
The 'check-all-boards' recipe can then extract these totals, just as
we do for the normal 'check' recipe, this makes is much easier to
spot if there are any unexpected failures when using
'check-all-boards'.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Change-Id: I15e307e6910ecbea5a5852e07757f892ea799536
|
|
gdb.arch/amd64-disp-step-avx.exp
In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp
on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then
I found support_displaced_stepping, which seems more appropriate and
descriptive.
Fix this by requiring support_displaced_stepping instead.
Tested on x86_64-freebsd.
|
|
With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into:
...
(gdb) continue
Continuing.
Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35
35 nop
(gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end
...
This happens while executing this bit of the test-case:
...
# Turn "debug displaced" on to make sure a displaced step is actually
# executed, not an inline step.
gdb_test_no_output "set debug displaced on"
gdb_test "continue" \
"Continuing.*prepared successfully .*Breakpoint.*, ${test_end_label} ().*" \
"continue to ${test_end_label}"
...
The problem is that on x86_64, displaced stepping is only supported for linux.
Consequently, the "prepared successfully" message is missing.
Fix this by requiring linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on x86_64-freebsd.
|
|
A user noticed that if the remote sends terminal escape sequences from
the "monitor" command, then these will not be correctly displayed when
in TUI mode.
I tracked this down to remote.c emitting one character at a time --
something the TUI output functions did not handle correctly.
I decided in the end to fix in this in the ui-file layer, because the
same bug seems to affect logging and, as is evidenced by the test case
in this patch, Python output in TUI mode.
The idea is simple: buffer escape sequences until they are either
complete or cannot possibly be recognized by gdb.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
On MSYS2, say we record a brief gdb session using TERM=dumb script:
...
$ gdb -q
(gdb) print 1
$1 = 1
(gdb) q
...
When looking at the resulting typescript, we notice something odd:
...
$ gdb -q^M
(gdb) print 1^M
$1 = 1^M^M
(gdb) q^M
...
For some reason, we have "$1 = 1\r\r\n(gdb) ".
Looking at the documentation of _setmode [1], it mentions translation mode
_O_TEXT as a mode in which "\n" is translated into "\r\n" on output.
So, it looks like this translation happens twice.
Add a command "maint set console-translation-mode <binary|text>" command that
allows us to set the translation mode of stdout/stderr to binary, such that we
get instead:
...
$ gdb -q -ex "maint set console-translation-mode binary"^M
(gdb) print 1^M
$1 = 1^M
(gdb) q^M
...
Since we run into this in the testsuite, add
"maint set console-translation-mode binary" to INTERNAL_GDBFLAGS.
Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre
Muller.
Compared to that proposal, I dropped the name testsuite-mode, because the
behaviour is not specific to the testsuite.
Also I chose values binary/text instead of on/off because eventually there may
be other translation mode values that we need [4].
Co-Authored-By: Pierre Muller <muller@sourceware.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode
[2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html
[3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
[4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants
|
|
The subsequent C++ification patch in this series will allocate one
instance of solib_ops per program space. That instance will be held in
struct program_space. As a small step towards this, add an `solib_ops
*` field to `struct program_space`. This field represents the solib_ops
currently used to manage the solibs in that program space. Initialize
it with the result of `gdbarch_so_ops` in `post_create_inferior`, and
use it whenever we need to do some solib stuff, rather than using
`gdbarch_so_ops` directly.
The difficulty here is knowing when exactly to set and unset the solib
ops. What I have here passes the testsuite on Linux, but with more
testing we will probably discover more spots where it's needed.
The C++ification patch will turn this field into a unique pointer.
With this patch, the message we get when running "info
linker-namespaces" becomes always the same, so update the test in
gdb.base/dlmopen-ns-ids.exp.
Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
running don't crash
While writing my solib_ops C++ification series, I broke this, and it
didn't seem to be caught by the testsuite. Add a test for those.
The exact message for "info linker-namespaces" varies depending on the
solib_ops of the target architecture (whether ops->num_active_namespaces
is nullptr or not). For now, just accept any message (a crash will
still be caught). A later patch in this series will make the message
consistent and update this test.
Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Commit:
commit b23903836007d1acaf7f8c059ab000ee83fcebfa
Date: Tue Mar 21 13:01:26 2023 +0100
gdb: linux-namespaces: enter user namespace when appropriate
added a new test gdb.base/user-namespace-attach.exp. It has been
reported that this test will sometimes fail, like this:
(gdb) attach 184732
Attaching to process 184732
warning: process 184732 is a zombie - the process has already terminated
ptrace: Operation not permitted.
(gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior
the test tries to run the 'unshare' application. Sometimes though,
the application is present, but the set of flags used is not
supported (maybe due to restrictions on the local machine), so we see
behaviour like this:
$ unshare --mount --map-root-user /bin/true; echo $?
unshare: unshare failed: Operation not permitted
1
Handle this case by first running 'unshare' with the same flags, but
using '/bin/true', if this fails then assume the flags are not
supported, and skip the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33108
|
|
This commit fixes a couple of issues relating to the pagination
prompt and styling. The pagination prompt is this one:
--Type <RET> for more, q to quit, c to continue without paging--
I did try to split this into multiple patches, based on the three
issues I describe below, but in the end, the fixes were all too
interconnected, so it ended up as one patch that makes two related,
but slightly different changes:
1. Within the pager_file class, relying on the m_applied_style
attribute of the wrapped m_stream, as is done when calling
m_stream->emit_style_escape, is not correct, so stop doing that, and
2. Failing to update m_applied_style within the pager_file class can
leave that attribute out of date, which can then lead to styling
errors later on, so ensure m_applied_style is always updated.
The problems I have seen are:
1. After quitting from a pagination prompt, the next command can
incorrectly style its output. This was reported as bug PR
gdb/31033, and is fixed by this commit.
2. The pagination prompt itself could be styled. The pagination
prompt should always be shown in the default style.
3. After continuing the output at a pagination prompt, GDB can fail
to restore the default style the next time the output (within the
same command) switches back to the default style.
There are tests for all these issues as part of this patch.
The pager_file class is a sub-class of wrapped_file, this means that a
pager_file is itself a ui_file, while it also manages a pointer to a
ui_file object (called m_stream). An instance of pager_file can be
installed as the gdb_stdout ui_file object.
Output sent to a pager_file is stored within an internal
buffer (called m_wrap_buffer) until we have a complete line, when the
content is flushed to the wrapped m_stream. If sufficient lines have
been written out then the pager_file will present the pagination
prompt and allow the user to continue viewing output, or quit the
current command.
As a pager_file is a ui_file, it has an m_applied_style member
variable.
The managed stream (m_stream) is also a ui_file, and so also has an
m_applied_style member variable.
In some places within the pager_file class we attempt to change the
current style of the m_stream using calls like this:
m_stream->emit_style_escape (style);
See pager_file::emit_style_escape, pager_file::prompt_for_continue,
and pager_file::puts. These calls will end up in
ui_file::emit_style_escape, which tries to skip emitting unnecessary
style escapes by checking if the requested style matches the current
m_applied_style value.
The m_applied_style value is updated by calls to the emit_style_escape
function.
The problem here is that most of the time pager_file doesn't change
the style of m_stream by calling m_stream->emit_style_escape. Most of
the time, style changes are performed by pager_file writing the escape
sequence into m_wrap_buffer, and then later flushing this buffer to
m_stream by calling m_stream->puts.
It has to be done this way. Calling m_stream->emit_style_escape
would, if it actually changed the style, immediately change the style
by emitting an escape sequence. But pager_file doesn't want that, it
wants the style change to happen later, when m_wrap_buffer is
flushed.
To avoid excessive style escape sequences being written into
m_wrap_buffer, the pager_file::m_applied_style performs a function
similar to the m_applied_style within m_stream, it tracks the current
style for the end of m_wrap_buffer, and only allows style escape
sequences to be emitted if the style is actually changing.
However, a consequence of this is the m_applied_style within m_stream,
is not updated, which means it will be out of sync with the actual
current style of m_stream. If we then try to make a call to
m_stream->emit_style_escape, if the style we are changing too happens
to match the out of date style in m_stream->m_applied_style, then the
style change will be ignored.
And this is indeed what we see in pager_file::prompt_for_continue with
the call:
m_stream->emit_style_escape (ui_file_style ());
As m_stream->m_applied_style is not being updated, it will always be
the default style, however m_stream itself might not actually be in
the default style. This call then will not emit an escape sequence as
the desired style matches the out of date m_applied_style.
The fix in this case is to call m_stream->puts directly, passing in
the escape sequence for the desired style. This will result in an
immediate change of style for m_stream, which fixes some of the
problems described above.
In fact, given that m_stream's m_applied_style is always going to be
out of sync, I think we should change all of the
m_stream->emit_style_escape calls to instead call m_stream->puts.
However, just changing to use puts doesn't fix all the problems.
I found that, if I run 'apropos time', then quit at the first
pagination prompt. If for the next command I run 'maintenance time' I
see the expected output:
"maintenance time" takes a numeric argument.
However, everything after the first double quote is given the command
name style rather than only styling the text between the double
quotes.
Here is GDB's stack while printing the above output:
#2 0x0000000001050d56 in ui_out::vmessage (this=0x7fff1238a150, in_style=..., format=0x1c05af0 "", args=0x7fff1238a288) at ../../src/gdb/ui-out.c:754
#3 0x000000000104db88 in ui_file::vprintf (this=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/ui-file.c:73
#4 0x00000000010bc754 in gdb_vprintf (stream=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/utils.c:1905
#5 0x00000000010bca20 in gdb_printf (format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n") at ../../src/gdb/utils.c:1945
#6 0x0000000000b6b29e in maintenance_time_display (args=0x0, from_tty=1) at ../../src/gdb/maint.c:128
The interesting frames here are #3, in here `this` is the pager_file
for GDB's stdout, and this passes its m_applied_style to frame #2 as
the `in_style` argument.
If the m_applied_style is wrong, then frame #2 will believe that the
wrong style is currently in use as the default style, and so, after
printing 'maintenance time' GDB will switch back to the wrong style.
So the question is, why is pager_file::m_applied_style wrong?
In pager_file::prompt_for_continue, there is an attempt to switch back
to the default style using:
m_stream->emit_style_escape (ui_file_style ());
If this is changed to a puts call (see above) then this still leaves
pager_file::m_applied_style out of date.
The right fix in this case is, I think, to instead do this:
this->emit_style_escape (ui_file_style ());
this will update pager_file::m_applied_style, and also send the
default style to m_stream using a puts call.
While writing the tests I noticed that I was getting unnecessary style
reset sequences emitted.
The problem is that, around pagination, we don't really know what
style is currently applied to m_stream. The
pager_file::m_applied_style tracks the style at the end of
m_wrap_buffer, but this can run ahead of the current m_stream style.
For example, if the screen is currently full, such that the next
character of output will trigger the pagination prompt, if the next
call is actually to pager_file::emit_style_escape, then
pager_file::m_applied_style will be updated, but the style of m_stream
will remain unchanged. When the next character is written to
pager_file::puts then the pagination prompt will be presented, and GDB
will try to switch m_stream back to the default style. Whether an
escape is emitted or not will depend on the m_applied_style value,
which we know is different than the actual style of m_stream.
It is, after all, only when m_wrap_buffer is flushed to m_stream that
the style of m_stream actually change.
And so, this commit also adds pager_file::m_stream_style. This new
variable tracks the current style of m_stream. This really is a
replacement for m_stream's ui_file::m_applied_style, which is not
accessible from pager_file.
When content is flushed from m_wrap_buffer to m_stream then the
current value of pager_file::m_applied_style becomes the current style
of m_stream. But, when m_wrap_buffer is filling up, but before it is
flushed, then pager_file::m_applied_style can change, but
m_stream_style will remain unchanged.
Now in pager_file::emit_style_escape we are able to skip some of the
direct calls to m_stream->puts() used to emit style escapes.
After all this there are still a few calls to
m_stream->emit_style_escape(). These are all in the wrap_here support
code. I think that these calls are technically broken, but don't
actually cause any issues due to the way styling works in GDB. I
certainly haven't been able to trigger any bugs from these calls yet.
I plan to "fix" these in the next commit just for completeness.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31033
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On openSUSE Tumbleweed (with python 3.13), I get:
...
(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("")
python gdb.warning()^M
Python Exception <class 'TypeError'>: \
function missing required argument 'text' (pos 1)^M
Error occurred in Python: function missing required argument 'text' (pos 1)^M
(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning()
...
But on openSUSE Leap 15.6 (with python 3.6), I get instead:
...
(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("")
python gdb.warning()^M
Python Exception <class 'TypeError'>: \
Required argument 'text' (pos 1) not found^M
Error occurred in Python: Required argument 'text' (pos 1) not found^M
(gdb) FAIL: gdb.python/py-warning.exp: python gdb.warning()
...
Fix this by updating the regexp.
Tested on x86_64-linux.
PR testsuite/33104
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33104
|
|
On x86_64-freebsd with test-case gdb.base/infcall-failure.exp I get:
...
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x0000000000400522 in func_segfault () at infcall-failure.c:24
24 return *p; /* Segfault here. */
Error in testing condition for breakpoint 2:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwind-on-signal on".
Evaluation of the expression containing the function
(func_segfault) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_cond_hits_segfault_test: continue
...
The problem is that the regexp in the test-case doesn't expect the
"Address not mapped to object." bit.
Fix this by updating the regexp.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on x86_64-freebsd and x86_64-linux.
|
|
PR testsuite/31831 reports the following failure in the
gdb.dap/log-message.exp test-case (formatted for readability):
...
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "Breakpoint 1 at 0x681: file log-message.c, line 23.\n"
},
"seq": 13
}
FAIL: $exp: logging output (checking body category)
...
for a gdb 14.2 based package.
The output event listed above is a result from the setBreakpoints request.
The test-case issues the setBreakpoints request and waits for the
corresponding response, but doesn't wait for the output event, and
consequently the output event is read by:
...
dap_wait_for_event_and_check "logging output" output \
{body category} console \
{body output} "got 23 - 23 = 0"
...
which triggers the failure.
I'm not able to reproduce this, but it looks worth fixing regardless.
We're fixing this on trunk though, and the output event looks different, and
there's one more output event:
...
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "No source file named log-message.c.\n"
},
"seq": 4
}
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "Breakpoint 1 (-source log-message.c -line 23) pending.\n"
},
"seq": 5
}
...
Fix this by waiting for these two output events, making the test-case a bit
more robust.
It is possible that one or both of these output events will be read by
dap_check_request_and_response "set breakpoint", and in that case restashing
them (for which there's currently no infrastructure) would be an easy way of
handling this. But I haven't been able to trigger that, so I'm leaving that
for if and when it does.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31831
|
|
A user pointed out that DAP allows the "threads" request to work when
the inferior is running. This is documented in the overview, not the
specification.
While looking into this, I found a few other issues:
* The _thread_name function was not marked @in_gdb_thread.
This isn't very important but is still an oversight.
* DAP requires all threads to have a name -- the field is not optional
in the "Thread" type.
* There was no test examining events resulting from the inferior
printing to stdout.
This patch fixes all these problems.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33080
|
|
I changed my system linker to 'mold', but then I saw some gdb test
failures. This patch fixes a subset of the failures.
dw2-strp.exp was failing, and investigating showed that there were two
.debug_str sections. I tracked this down to the .S file not using the
correct section flags.
This patch fixes this problem, plus the other instances I could find.
(Strangely, these did not all cause problems, however.) I also
changed the DWARF assembler to always use these flags for .debug_str.
|
|
Compilers can put a sequence aligning the stack at the entry of a
function. However with -fcf-protection enabled, "endbr64" is
generated before. Current implementation of amd64 prologue analyzer
first checks for stack alignment and then for "endbr64", which is not
correct. This behavior was introduced with patch "gdb: handle endbr64
instruction in amd64_analyze_prologue". In case both are generated,
prologue will not be skipped. This patch swaps the order so that
"endbr64" is checked first and adds a regression test. i386-tdep
implementation also already had those checked in the correct order,
that is stack alignment is after endbr64.
Given such source compiled with gcc 11.4.0 via:
gcc -O0 main.c -o main
```
#include <alloca.h>
void
foo (int id)
{
volatile __attribute__ ((__aligned__ (64))) int a;
volatile char *p = (char *) alloca (id * 12);
p[2] = 'b';
}
int
main (int argc, char **argv)
{
foo (argc + 1);
return 1;
}
```
we get such function entry for foo (generated with objdump -d):
```
0000000000001149 <foo>:
1149: f3 0f 1e fa endbr64
114d: 4c 8d 54 24 08 lea 0x8(%rsp),%r10
1152: 48 83 e4 c0 and $0xffffffffffffffc0,%rsp
1156: 41 ff 72 f8 push -0x8(%r10)
115a: 55 push %rbp
115b: 48 89 e5 mov %rsp,%rbp
115e: 41 52 push %r10
1160: 48 81 ec a8 00 00 00 sub $0xa8,%rsp
1167: 89 7d 8c mov %edi,-0x74(%rbp)
...
```
The 3 instructions following endbr64 align the stack. If we were to set
a breakpoint on foo, gdb would set it at function's entry:
```
(gdb) b foo
Breakpoint 1 at 0x1149
(gdb) r
...
Breakpoint 1, 0x0000555555555149 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
=> 0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: lea 0x8(%rsp),%r10
0x0000555555555152 <+9>: and $0xffffffffffffffc0,%rsp
0x0000555555555156 <+13>: push -0x8(%r10)
0x000055555555515a <+17>: push %rbp
0x000055555555515b <+18>: mov %rsp,%rbp
0x000055555555515e <+21>: push %r10
0x0000555555555160 <+23>: sub $0xa8,%rsp
0x0000555555555167 <+30>: mov %edi,-0x74(%rbp)
...
```
With this patch fixing the order of checked instructions, gdb can
properly analyze the prologue:
```
(gdb) b foo
Breakpoint 1 at 0x115e
(gdb) r
...
Breakpoint 1, 0x000055555555515e in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: lea 0x8(%rsp),%r10
0x0000555555555152 <+9>: and $0xffffffffffffffc0,%rsp
0x0000555555555156 <+13>: push -0x8(%r10)
0x000055555555515a <+17>: push %rbp
0x000055555555515b <+18>: mov %rsp,%rbp
=> 0x000055555555515e <+21>: push %r10
0x0000555555555160 <+23>: sub $0xa8,%rsp
0x0000555555555167 <+30>: mov %edi,-0x74(%rbp)
...
```
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Update the make-check-all.sh script to use TESTS rather than passing
the test names within RUNTESTFLAGS. This addresses the following
issue:
I was running some tests like this:
make -C gdb check-all-boards TESTS="gdb.base/break*.exp"
And I was finding that I would get lots of DUPLICATE test results,
which is not what I expected.
What's happening here is that the 'make check-all-boards' rule runs
the 'make-check-all.sh' script, which then runs 'make check' with
various board files.
However, passing TESTS=... to the initial 'make check-all-boards'
command invocation automatically causes the TESTS value to be added to
the MAKEFLAGS environment variable, this is then picked up by the
later calls to 'make check'.
Now, in GDB's testfile/Makefile, we check for TESTS, and if this is
set, we expand the value and set `expanded_tests_or_none`. Otherwise,
if TESTS is not set, expanded_tests_or_none is left empty.
Finally, when handling 'make check', the value of
`expanded_tests_or_none` is passed through to dejagnu, along with the
RUNTESTFLAGS value.
What this means is that, when make-check-all.sh passes the test names
in the RUNTESTFLAGS, then dejagnu ends up seeing the list of tests
twice, once from RUNTESTFLAGS, and once from expanded_tests_or_none,
and this is why I was seeing duplicate testnames.
The easiest fix for the above is to have make-check-all.sh pass the
test names using TESTS="...", this will override the TESTS="..." value
already present in MAKEFLAGS, and means dejagnu will see the test
names just once.
Additionally, this is a start towards allowing parallel test running
from the make-check-all.sh script. Parallel test running only works
if the test names are passed in TESTS, and not in RUNTESTFLAGS.
Currently, in testsuite/Makefile, if RUNTESTFLAGS is not empty, then
we force single threaded test running. But with this change, at least
for the `local` board, we can now benefit from multi-threaded test
running, as this board has an empty RUNTESTFLAGS now. For the other
boards we'd need to set FORCE_PARALLEL in order to benefit from
parallel test running, but we'll need to double check that all the
board files actually support parallel test running first, so I'm
leaving that for another day.
|
|
This commit adds filename completion for the shell command part of
the pipe command. This is a follow on from this commit:
commit 036e5c0c9121d0ac691dbf408a3bdf2bf3501d0f
Date: Mon May 19 20:54:54 2025 +0100
gdb: use quoted filename completion for the shell command
which fixed the completion for the 'shell' command itself.
Like with the 'shell' command, we don't offer completions of command
names pulled from $PATH, we just offer filename completion, which is
often useful for arguments being passed to commands. Maybe in the
future we could add completion for command names too (for both 'pipe'
and the 'shell' command), but that is left for a future commit.
There's some additional testing.
|
|
The use of user namespaces is required for normal users to use mount
namespaces. Consider trying this as an unprivileged user:
$ unshare --mount /bin/true
unshare: unshare failed: Operation not permitted
The problem here is that an unprivileged user doesn't have the
required permissions to create a new mount namespace. If, instead, we
do this:
$ unshare --mount --map-root-user /bin/true
then this will succeed. The new option causes unshare to create a
user namespace in which the unprivileged user is mapped to UID/GID 0,
and so gains all privileges (inside the namespace), the user is then
able to create the mount namespace as required.
So, how does this relate to GDB?
When a user attaches to a process running in a separate mount
namespace, GDB makes use of a separate helper process (see
linux_mntns_get_helper in nat/linux-namespaces.c), which will then use
the `setns` function to enter (or try to enter) the mount namespace of
the process GDB is attaching too. The helper process will then handle
file I/O requests received from GDB, and return the results back to
GDB, this allows GDB to access files within the mount namespace.
The problem here is that, switching to a mount namespace requires that
a process hold CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities within
its user namespace (actually it's a little more complex, see 'man 2
setns'). Assuming GDB is running as an unprivileged user, then GDB
will not have the required permissions.
However, if GDB enters the user namespace that the `unshare` process
created, then the current user will be mapped to UID/GID 0, and will
have the required permissions.
And so, this patch extends linux_mntns_access_fs (in
nat/linux-namespace.c) to first try and switch to the user namespace
of the inferior before trying to switch to the mount namespace. If
the inferior does have a user namespace, and does have elevated
privileges within that namespace, then this first switch by GDB will
mean that the second step, into the mount namespace, will succeed.
If there is no user namespace, or the inferior doesn't have elevated
privileges within the user namespace, then the switch into the mount
namespace will fail, just as it currently does, and the user will need
to give elevated privileges to GDB via some other mechanism (e.g. run
as root).
This work was originally posted here:
https://inbox.sourceware.org/gdb-patches/20230321120126.1418012-1-benjamin@sipsolutions.net
I (Andrew Burgess) have made some cleanups to the code to comply with
GDB's coding standard, and the test is entirely mine. This commit
message is also entirely mine -- the original message was very terse
and required the reader to understand how the various namespaces
work and interact. The above is my attempt to document what I now
understand about the problem being fixed.
I've left the original author in place as the core of the GDB change
itself is largely as originally presented, but any inaccuracies in the
commit message, or problems with the test, are all mine.
Co-Authored-by: Andrew Burgess <aburgess@redhat.com>
|
|
This commit works around a problem introduced by commit:
commit e58beedf2c8a1e0c78e0f57aeab3934de9416bfc
Date: Tue Jan 23 16:00:59 2024 +0000
gdb: attach to a process when the executable has been deleted
The above commit extended GDB for Linux, so that, of the executable
for a process had been deleted, GDB would instead try to use
/proc/PID/exe as the executable.
This worked by updating linux_proc_pid_to_exec_file to introduce the
/proc/PID/exe fallback. However, the result of
linux_proc_pid_to_exec_file is then passed to exec_file_find to
actually find the executable, and exec_file_find, will take into
account the sysroot. In addition, if GDB is attaching to a process in
a different MNT and/or PID namespace then the executable lookup is
done within that namespace.
This all means two things:
1. Just because linux_proc_pid_to_exec_file cannot see the
executable doesn't mean that GDB is actually going to fail to
find the executable, and
2. returning /proc/PID/exe isn't useful if we know GDB is then going
to look for this within a sysroot, or within some other
namespace (where PIDs might be different).
There was an initial attempt to fix this issue here:
https://inbox.sourceware.org/gdb-patches/20250511141517.2455092-4-kilger@sec.in.tum.de/
This proposal addresses the issue in PR gdb/32955, which is all about
the namespace side of the problem. The fix in this original proposal
is to check the MNT namespace inside linux_proc_pid_to_exec_file, and
for the namespace problem this is fine. But we should also consider
the sysroot problem.
And for the sysroot problem, the fix cannot fully live inside
linux_proc_pid_to_exec_file, as linux_proc_pid_to_exec_file is shared
between GDB and gdbserver, and gdbserver has no sysroot.
And so, I propose a slightly bigger change.
Now, linux_proc_pid_to_exec_file takes a flag which indicates if
GDB (or gdbserver) will look for the inferior executable in the
local file system, where local means the same file system as GDB (or
gdbserver) is running in.
This local file system check is true if:
1. The MNT namespace of the inferior is the same as for GDB, and
2. for GDB only, the sysroot must either be empty, or 'target:'.
If the local file system check is false then GDB (or gdbserver) is
going to look elsewhere for the inferior executable, and so, falling
back to /proc/PID/exe should not be done, as GDB will end up looking
for this file in the sysroot, or within the alternative MNT
namespace (which in also likely to be a different PID namespace).
Now this is all a bit of a shame really. It would be nice if
linux_proc_pid_to_exec_file could return /proc/PID/exe in such a way
that exec_file_find would know that the file should NOT be looked for
in the sysroot, or in the alternative namespace. But fixing that
problem would be a much bigger change, so for now lets just disable
the /proc/PID/exe fallback for cases where it might not work.
For testing, the sysroot case is now tested.
I don't believe we have any alternative namespace testing. It would
certainly be interesting to add some, but I'm not proposing any with
this patch, so the code for checking the MNT namespace has been tested
manually by me, but isn't covered by a new test I'm adding here.
Author of the original fix is listed as co-author here. Credit for
identifying the original problem, and proposing a solution belongs to
them.
Co-Authored-By: Fabian Kilger <kilger@sec.in.tum.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32955
|
|
Currently gdbserver uses the require_int() function to parse the
requested offset (in vFile::pread packet and the like). This function
allows integers up to 0x7fffffff (to fit in 32-bit int), however the
offset (for the pread system call) has an off_t type which can be
larger than 32-bit.
This patch allows require_int() function to parse offset up to the
maximum value implied by the off_t type.
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: I3691bcc1ab1838c0db7f8b82d297d276a5419c8c
|
|
`pre-commit run --all-files` found this.
Change-Id: I8db09b12cf184d32351ff2c579bdaa8cf6f80ac3
|
|
Change the messages to reflect that these numbers includes type units,
not only compile units.
Change-Id: Id2f511d4666e5cf92112be917d72ff76791b7e1d
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
This commit adds a new gdb.warning() function. This function takes a
string and then calls GDB's internal warning() function. This will
display the string as a warning.
Using gdb.warning() means that the message will get the new emoji
prefix if the user has that feature turned on. Also, the message will
be sent to gdb.STDERR without the user having to remember to print to
the correct stream.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit continues the work of the previous two commits.
In the following commits I added the target_fileio_stat function, and
the target_ops::fileio_stat member function:
* 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
* 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
* 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
* 22836ca8859 gdb: check for multiple matching build-id files
Unfortunately I messed up, despite being called 'stat' these function
actually performed an 'lstat'. The 'lstat' is the correct (required)
implementation, it's the naming that is wrong.
Additionally, to support remote targets, these commit added the
vFile::stat packet, which again, performed an 'lstat'.
In the previous two commits I changed the GDB code to replace 'stat'
with 'lstat' in the fileio function names. I then added a new
vFile:lstat packet which GDB now uses instead of vFile:stat.
And that just leaves the vFile:stat packet which is, right now,
performing an 'lstat'.
Now, clearly when I wrote this code I fully intended for this packet
to perform an lstat, it's the lstat that I needed. But now, I think,
we should "fix" vFile:stat to actually perform a 'stat'.
This is risky. This is a change in remote protocol behaviour.
Reasons why this might be OK:
- vFile:stat was only added in GDB 16, so it's not been "in the
wild" for too long yet. If we're quick, we might be able to "fix"
this before anyone realises I messed up.
- The documentation for vFile:stat is pretty vague. It certainly
doesn't explicitly say "this does an lstat". Most implementers
would (I think), given the name, start by assuming this should be
a 'stat' (given the name). Only if they ran the full GDB
testsuite, or examined GDB's implementation, would they know to
use lstat.
Reasons why this might not be OK:
- Some other debug client could be connecting to gdbserver, sending
vFile:stat and expecting to get lstat behaviour. This would break
after this patch.
- Some other remote server might have implemented vFile:stat
support, and either figured out, or copied, the lstat behaviour
from gdbserver. This remote server would technically be wrong
after this commit, but as GDB no longer uses vFile:stat, then this
will only become a problem if/when GDB or some other client starts
to use vFile:stat in the future.
Given the vague documentation for vFile:stat, and that it was only
added in GDB 16, I think we should fix it now to perform a 'stat', and
that is what this commit does.
The change in behaviour is documented in the NEWS file. I've improved
the vFile:stat documentation in the manual to better explain what is
expected from this packet, and I've extended the existing test to
cover vFile:stat.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In the following commits I added the target_fileio_stat function, and
the target_ops::fileio_stat member function:
* 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
* 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
* 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
* 22836ca8859 gdb: check for multiple matching build-id files
Unfortunately I messed up, despite being called 'stat' these function
actually performed an 'lstat'. The 'lstat' is the correct (required)
implementation, it's the naming that is wrong.
In the previous commit I fixed the naming within GDB, renaming 'stat'
to 'lstat' throughout.
However, in order to support target_fileio_stat (as was) on remote
targets, the above patches added the vFile:stat packet, which actually
performed an 'lstat' call. This is really quite unfortunate, and I'd
like to do as much as I can to try and clean up this mess. But I'm
mindful that changing packets is not really the done thing.
So, this commit doesn't change anything.
Instead, this commit adds vFile:lstat as a new packet.
Currently, this packet is handled identically as vFile:stat, the
packet performs an 'lstat' call.
I then update GDB to send the new vFile:lstat instead of vFile:stat
for the remote_target::fileio_lstat implementation.
After this commit GDB will never send the vFile:stat packet.
However, I have retained the 'set remote hostio-stat-packet' control
flag, just in case someone was trying to set this somewhere.
Then there's one test in the testsuite which used to disable the
vFile:stat packet, that test is updated to now disable vFile:lstat.
There's a new test that does a more direct test of vFile:lstat. This
new test can be extended to also test vFile:stat, but that is left for
the next commit.
And so, after this commit, GDB sends the new vFile:lstat packet in
order to implement target_ops::fileio_lstat. The new packet is more
clearly documented than vFile:stat is. But critically, this change
doesn't risk breaking any other clients or servers that implement
GDB's remote protocol.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With MSYS2 and test-case gdb.ada/assign_1.exp, we get:
...
(gdb) dir^M
Reinitialize source path to empty? (y or n) \
[answered Y; input not from terminal]^M^M
Source directories searched: $cdir;$cwd^M^M
(gdb)
...
GDB automatically answers the query, because interactive-mode is off:
...
(gdb) show interactive-mode^M
Debugger's interactive mode is auto (currently off).^M^M
...
The correct value is on, because GDB was started in a terminal.
For some reason, the auto value of interactive-mode is off instead. According
to this patch [1], gdb doesn't recognize the pipes used by DejaGnu testsuite
as an interactive setup.
Fix this by adding "set interactive-mode on" to INTERNAL_GDBFLAGS, such that
we get:
...
(gdb) dir^M
Reinitialize source path to empty? (y or n) y^M
Source directories searched: $cdir;$cwd^M^M
(gdb)
...
and no longer need fixes like commit be740e7cc62 ("testsuite: skip
confirmation in 'gdb_reinitialize_dir'")
The fix is essentially the same as in aforementioned patch.
For consistency, we apply the fix for all platforms.
Co-Authored-By: Pierre Muller <muller@sourceware.org>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
|
|
With MSYS2 and default TERM=xterm-256color (as well as with xterm and ansi), I
get:
...
builtin_spawn gdb -q ...
^[[6n(gdb) ERROR: GDB never initialized.
...
This is not specific to gdb, other tools produce the same CSI sequence, and
consequently we run into trouble in other places (like get_compiler_info).
Fix this by default-setting TERM to dumb.
We do this for all platforms, to avoid test-cases passing on one platform but
failing on another.
For test-cases that set TERM to something other than dumb, handle the CSI
sequence in default_gdb_start.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/33072
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33072
|
|
amd_dbgapi_target_breakpoint::check_status
ROCgdb handles target events very slowly when running a test case like
this, where a breakpoint is preset on HipTest::vectorADD:
for (int i=0; i < numDevices; ++i) {
HIPCHECK(hipSetDevice(i));
hipLaunchKernelGGL(HipTest::vectorADD, dim3(blocks), dim3(threadsPerBlock), 0, stream[i],
static_cast<const int*>(A_d[i]), static_cast<const int*>(B_d[i]), C_d[i], N);
}
What happens is:
- A kernel is launched
- The internal runtime breakpoint is hit during the second
hipLaunchKernelGGL call, which causes
amd_dbgapi_target_breakpoint::check_status to be called
- Meanwhile, all waves of the kernel hit the breakpoint on vectorADD
- amd_dbgapi_target_breakpoint::check_status calls process_event_queue,
which pulls the thousand of breakpoint hit events from the kernel
- As part of handling the breakpoint hit events, we write the PC of the
waves that stopped to decrement it. Because the forward progress
requirement is not disabled, this causes a suspend/resume of the
queue each time, which is time-consuming.
The stack trace where this all happens is:
#32 0x00007ffff6b9abda in amd_dbgapi_write_register (wave_id=..., register_id=..., offset=0, value_size=8, value=0x7fffea9fdcc0) at /home/smarchi/src/amd-dbgapi/src/register.cpp:587
#33 0x00005555588c0bed in amd_dbgapi_target::store_registers (this=0x55555c7b1d20 <the_amd_dbgapi_target>, regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2504
#34 0x000055555a5186a1 in target_store_registers (regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/target.c:3973
#35 0x0000555559fab831 in regcache::raw_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:890
#36 0x0000555559fabd2b in regcache::cooked_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:915
#37 0x0000555559fc3ca5 in regcache::cooked_write<unsigned long, void> (this=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:850
#38 0x0000555559fab09a in regcache_cooked_write_unsigned (regcache=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:858
#39 0x0000555559fb0678 in regcache_write_pc (regcache=0x507000002240, pc=0x7ffff62bd900) at /home/smarchi/src/wt/amd/gdb/regcache.c:1460
#40 0x00005555588bb37d in process_one_event (event_id=..., event_kind=AMD_DBGAPI_EVENT_KIND_WAVE_STOP) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1873
#41 0x00005555588bbf7b in process_event_queue (process_id=..., until_event_kind=AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2006
#42 0x00005555588b1aca in amd_dbgapi_target_breakpoint::check_status (this=0x511000140900, bs=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:890
#43 0x0000555558c50080 in bpstat_stop_status (aspace=0x5070000061b0, bp_addr=0x7fffed0b9ab0, thread=0x518000026c80, ws=..., stop_chain=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/breakpoint.c:6126
#44 0x000055555984f4ff in handle_signal_stop (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:7169
#45 0x000055555984b889 in handle_inferior_event (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:6621
#46 0x000055555983eab6 in fetch_inferior_event () at /home/smarchi/src/wt/amd/gdb/infrun.c:4750
#47 0x00005555597caa5f in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/wt/amd/gdb/inf-loop.c:42
#48 0x00005555588b838e in handle_target_event (client_data=0x0) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1513
Fix that performance problem by disabling the forward progress
requirement in amd_dbgapi_target_breakpoint::check_status, before
calling process_event_queue, so that we can process all events
efficiently.
Since the same performance problem could theoritically happen any time
process_event_queue is called with forward progress requirement enabled,
add an assert to ensure that forward progress requirement is disabled
when process_event_queue is invoked. This makes it necessary to add a
require_forward_progress call to amd_dbgapi_finalize_core_attach. It
looks a bit strange, since core files don't have execution, but it
doesn't hurt.
Add a test that replicates this scenario. The test launches a kernel
that hits a breakpoint (with an always false condition) repeatedly.
Meanwhile, the host process loads an unloads a code object, causing
check_status to be called.
Bug: SWDEV-482511
Change-Id: Ida86340d679e6bd8462712953458c07ba3fd49ec
Approved-by: Lancelot Six <lancelot.six@amd.com>
|
|
When running test-case gdb.python/py-source-styling-2.exp with TERM=dumb, I
get:
...
(gdb) set style enabled on^M
warning: The current terminal doesn't support styling. \
Styled output might not appear as expected.^M
(gdb) FAIL: $exp: set style enabled on
...
Fix this by using with_ansi_styling_terminal on clean_restart.
Tested on x86_64-linux.
|
|
Setting a BP on a line like this would incorrectly yield two BP locations:
01 void two () { {int var = 0;} }
(gdb) break 1
Breakpoint 1 at 0x1164: main.cpp:1. (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000001164 in two() at main.cpp:1
1.2 y 0x0000000000001164 in two() at main.cpp:1
In this case decode_digits_ordinary () returns two SALs, exactly matching the
requested line. One for the entry PC and one for the prologue end PC. This
was
tested with GCC, CLANG and ICPX. Subsequent code tries to skip the prologue
on these PCs, which in turn makes them the same.
To fix this, ignore SALs with the same PC and program space when adding to the
list of SALs.
This will then properly set only one location:
(gdb) break 1
Breakpoint 1 at 0x1164: file main.cpp, line 1
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000001164 in two() at main.cpp:1
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The Windows port does not support multi-process debugging. Testcases
that want to exercise multi-process currently FAIL and some hit
cascading timeouts. Add a new allow_multi_inferior_tests procedure,
meant to be used with require, and sprinkle it throughout testcases as
needed.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I4a10d8f04f9fa10f4b751f140ad0a6d31fbd9dfb
|
|
Cygwin debugging does not support follow fork. There is currently no
interface between the debugger and the Cygwin runtime to be able to
intercept forks and execs. Consequently, testcases that try to
exercise fork/exec all FAIL, and several hit long cascading timeouts.
Add a new allow_fork_tests procedure, meant to be used with require,
and sprinkle it throughout testcases that exercise fork.
Note that some tests currently are skipped on targets other than
Linux, with something like:
# Until "set follow-fork-mode" and "catch vfork" are implemented on
# other targets...
#
if {![istarget "*-linux*"]} {
continue
}
However, some BSD ports also support fork debugging nowadays, and the
testcases were never adjusted... That is why the new allow_fork_tests
procedure doesn't look for linux.
With this patch, on Cygwin, I get this:
$ make check TESTS="*/*fork*.exp"
...
=== gdb Summary ===
# of expected passes 6
# of untested testcases 1
# of unsupported tests 31
Reviewed-By: Keith Seitz <keiths@redhat.com>
Change-Id: I0c5e8c574d1f61b28d370c22a0b0b6bc3efaf978
|
|
Running gdb.multi/attach-no-multi-process.exp on Cygwin, where
GDBserver does not support non-stop mode, I see:
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: info threads
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)
Let's ignore the first "info threads" fail. The timeouts look like
this:
builtin_spawn /home/alves/gdb-cache-cygwin/gdb/../gdbserver/gdbserver --once --multi localhost:2346
Listening on port 2346
target extended-remote localhost:2346
Remote debugging using localhost:2346
Non-stop mode requested, but remote does not support non-stop
(gdb) gdb_do_cache: can_spawn_for_attach ( )
builtin_spawn /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.multi/attach-no-multi-process/attach-no-multi-process
attach 14540
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
info threads
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)
Note the "Non-stop mode requested, but remote does not support
non-stop" line.
The intro to gdb_target_cmd_ext says:
# gdb_target_cmd_ext
# Send gdb the "target" command. Returns 0 on success, 1 on failure, 2 on
# unsupported.
That's perfect here, we can just use gdb_target_cmd_ext instead of
gdb_target_cmd, and check for 2 (unsupported). That's what this patch
does.
However gdb_target_cmd_ext incorrectly returns 1 instead of 2 for the
case where the remote target says it does not support non-stop. That
is also fixed by this patch.
With this, we no longer get those timeout fails. We get instead:
target extended-remote localhost:2346
Remote debugging using localhost:2346
Non-stop mode requested, but remote does not support non-stop
(gdb) UNSUPPORTED: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: non-stop RSP
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I1ab3162f74200c6c02a17a0600b102d2d12db236
|
|
On Cygwin, starting an inferior under GDB, and detaching it, quitting
GDB, and then closing the shell, like so:
(gdb) start
(gdb) detach
(gdb) quit
# close shell
... hangs the parent shell of GDB (not GDB!) until the inferior
process that was detached (as it is still using the same terminal GDB
was using) exits too.
This leads to odd failures in gdb.base/watchpoint-hw-attach.exp like
so:
detach
Detaching from program: .../outputs/gdb.base/watchpoint-hw-attach/watchpoint-hw-attach, process 16580
[Inferior 1 (process 16580) detached]
(gdb) FAIL: gdb.base/watchpoint-hw-attach.exp: detach
Fix this by converting the testcase to spawn the inferior outside GDB,
with spawn_wait_for_attach.
With this patch, the testcase passes cleanly on Cygwin, for me.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I8e3884073a510d6fd2fff611e1d26fc808adc4fa
|
|
Running gdb.cp/cpexprs.exp on x86-64 GNU/Linux, I see:
break base::~base
Breakpoint 117 at 0x555555555d90: file .../src/gdb/testsuite/gdb.cp/cpexprs.cc, line 135.
(gdb) continue
Continuing.
Breakpoint 117, base::~base (this=0x7fffffffd0f8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
135 ~base (void) { } // base::~base
(gdb) PASS: gdb.cp/cpexprs.exp: continue to base::~base
Here, the breakpoint only got one location because both the in-charge
and the not-in-charge dtors are identical and got the same address:
$ nm -A ./testsuite/outputs/gdb.cp/cpexprs/cpexprs| c++filt |grep "~base"
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
While on Cygwin, we get two locations for the same breakpoint, which
the testcase isn't expecting:
break base::~base
Breakpoint 117 at 0x100402678: base::~base. (2 locations)
(gdb) continue
Continuing.
Thread 1 "cpexprs" hit Breakpoint 117.1, base::~base (this=0x7ffffcaf8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
135 ~base (void) { } // base::~base
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to base::~base
We got two locations because the in-charge and the not-in-charge dtors
have different addresses:
$ nm -A outputs/gdb.cp/cpexprs/cpexprs.exe | c++filt | grep "~base"
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402680 T base::~base()
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402690 T base::~base()
On Cygwin, we also see the typical failure due to not expecting the
inferior to be multi-threaded:
(gdb) continue
Continuing.
[New Thread 628.0xe08]
Thread 1 "cpexprs" hit Breakpoint 200, test_function (argc=1, argv=0x7ffffcc20) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:336
336 derived d;
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to test_function for policyd3::~policyd
Both issues are fixed by this patch, and now the testcase passes
cleanly on Cygwin, for me.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Change-Id: If7eb95d595f083f36dfebf9045c0fc40ef5c5df1
|
|
I noticed on Cygwin, gdb.thread/thread-execl.exp would hang, (not that
surprising since we can't follow-exec on Cygwin). Looking at the
process list running on the machine, we end up with a thread-execl.exe
process constantly respawning another process [1].
We see the same constant-reexec if we launch gdb.thread/thread-execl
manually on the shell:
$ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
# * doesn't exit, constantly re-execing *
^C
Prevent this leftover constantly-re-execing scenario by making the
testcase program only exec once. We now get:
$ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
$ # exits immediately after one exec.
On Cygwin, the testcase now fails reasonably quickly, and doesn't
leave stale processes behind.
Still passes cleanly on x86-64 GNU/Linux.
[1] Cygwin's exec emulation spawns a new Windows process for the new
image.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I0de1136cf2ef7e89465189bc43489a2139a80efb
|
|
Cygwin supports dumping ELF cores via a dumper.exe utility, see
https://www.cygwin.com/cygwin-ug-net/dumper.html.
When I run a testcase that has the "kernel" generate a corefile, like
gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and
generates an ELF core file, however, the testsuite doesn't find the
generated core:
Running /home/alves/gdb/src/gdb/testsuite/gdb.base/corefile.exp ...
WARNING: can't generate a core file - core tests suppressed - check ulimit -c
The file is correctly put under $coredir, e.g., like so:
outputs/gdb.base/corefile/coredir.8926/corefile.exe.core
The problem is in this line in core_find:
foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" {
Note that that isn't looking for "${binfile}.core" inside
${coredir}... That is fixed in this patch.
However, that still isn't sufficient for Cygwin + dumper, as in that
case the core is going to be called foo.exe.core, not foo.core. Fix
that by looking for foo.exe.core in the core dir as well.
With this, gdb.base/corefile.exp and other tests that use core_find
now run. They don't pass cleanly, but at least now they're exercised.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e
|
|
The gdb.base/sigall.exp testcase has many FAILs on Cygwin currently.
From:
Thread 1 "sigall" received signal SIGPWR, Power fail/restart.
0x00007ffeac9ed134 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) FAIL: gdb.base/sigall.exp: get signal LOST
we see two issues. The test is expecting "Program received ..." which
only appears if the inferior is single-threaded. All Cygwin inferiors
are multi-threaded, because both Windows and the Cygwin runtime spawn
a few helper threads.
And then, SIGLOST is the same as SIGPWR on Cygwin. The testcase
already knows to treat them the same on SPARC64 GNU/Linux. We just
need to extend the relevant code to treat Cygwin the same.
With this, the test passes cleanly on Cygwin.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ie3553d043f4aeafafc011347b6cb61ed58501667
|
|
The gdb.arch/amd64-watchpoint-downgrade.exp testcase is assuming the
output of debugging a single-thread program, like so, on e.g.,
GNU/Linux:
starti
Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
warning: watchpoint 1 downgraded to software watchpoint
Program stopped.
0x00007ffff7fe32b0 in _start () from /lib64/ld-linux-x86-64.so.2
However, on Cygwin, where all inferiors are multi-threaded (because
both Windows and the Cygwin runtime spawn a few helper threads), we
get:
starti
Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
[New Thread 4652.0x17e4]
warning: watchpoint 1 downgraded to software watchpoint
Thread 1 stopped.
0x00007ffbfc1c0911 in ntdll!LdrInitShimEngineDynamic () from C:/Windows/SYSTEM32/ntdll.dll
This commit adjusts the testcase to work with either output.
(Note GDB may print a thread name after the thread number.)
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I3aedfec04924ea3fb3bb87ba3251e2b720f8d59c
|
|
On Cygwin, all inferiors are multi-threaded, because both Windows and
the Cygwin runtime spawn a few helper threads. Adjust the
gdb.base/bp-permanent.exp testcase to work with either single- or
multi-threaded inferiors.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I28935b34fc9f739c2a5490e83aa4995d29927be2
|
|
Currently on Cygwin, I get:
Running /home/alves/gdb/src/gdb/testsuite/gdb.base/bp-cond-failure.exp ...
FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: single-loc: continue
On GNU/Linux, we see:
Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
21 return 0; /* Multi-location breakpoint here. */
(gdb) PASS: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
While on Cygwin, we see:
Thread 1 "bp-cond-failure" hit Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
21 return 0; /* Multi-location breakpoint here. */
(gdb) FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
The difference is the "Thread 1" part in the beginning of the quoted
output. It appears on Cygwin, but not on Linux. That's because on
Cygwin, all inferiors are multi-threaded, because both Windows and the
Cygwin runtime spawn a few helper threads.
Fix this by adjusting the gdb.base/bp-cond-failure.exp testcase to
work with either single- or multi-threaded inferiors.
The testcase passes cleanly for me after this.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I5ff11d06ac1748d044cef025f1e78b8f84ad3349
|
|
On s390x-linux, with test-case gdb.ada/dyn-bit-offset.exp and gcc 7.5.0 I get:
...
(gdb) print spr^M
$1 = (discr => 3, array_field => (-5, -6, -7), field => -6, another_field => -6)^M
(gdb) FAIL: $exp: print spr
print spr.field^M
$2 = -6^M
(gdb) FAIL: $exp: print spr.field
...
On x86_64-linux, with the same compiler version I get:
...
(gdb) print spr^M
$1 = (discr => 3, array_field => (-5, -6, -7), field => -4, another_field => -4)^M
(gdb) XFAIL: $exp: print spr
print spr.field^M
$2 = -4^M
(gdb) PASS: $exp: print spr.field
...
In both cases, we're hitting the same compiler problem, but it manifests
differently on little and big endian.
Make sure the values seen for both little and big endian trigger xfails
for both tests.
Printing spr.field gives the expected value -4 for x86_64, but that's an
accident. Change the actual spr.field value to -5, to make sure
that we get the same number of xfails on x86_64 and s390x.
Finally, make the xfails conditional on the compiler version.
Tested using gcc 7.5.0 on both x86_64-linux and s390x-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33042
https://sourceware.org/bugzilla/show_bug.cgi?id=33042
|
|
When the convenience variable $_linker_namespace was introduced, I meant
for it to print the namespace of the frame that where the user was
stopped. However, due to confusing what "current_frame" and
"selected_frame" meant, it instead printed the namespace of the
lowermost frame.
This commit updates the code to follow my original intent. Since the
variable was never in a GDB release, updating the behavior should not
cause any disruption. It also adds a test to verify the functionality.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Internal AdaCore testing using -gdwarf-4 found a spot where GCC will
emit a negative DW_AT_bit_offset. However, my recent signed/unsigned
changes assumed that this value had to be positive.
I feel this bug somewhat invalidates my previous thinking about how
DWARF attributes should be handled.
In particular, both GCC and LLVM at understand that a negative bit
offset can be generated -- but for positive offsets they might use a
smaller "data" form, which is expected not to be sign-extended. LLVM
has similar code but GCC does:
if (bit_offset < 0)
add_AT_int (die, DW_AT_bit_offset, bit_offset);
else
add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT) bit_offset);
What this means is that this attribute is "signed but default
unsigned".
To fix this, I've added a new attribute::confused_constant method.
This should be used when a constant value might be signed, but where
narrow forms (e.g., DW_FORM_data1) should *not* cause sign extension.
I examined the GCC and LLVM DWARF writers to come up with the list of
attributes where this applies, namely DW_AT_bit_offset,
DW_AT_const_value and DW_AT_data_member_location (GCC only, but LLVM
always emits it as unsigned, so we're safe here).
This patch corrects the bug and imports the relevant test case.
Regression tested on x86-64 Fedora 41.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Turns out that using 'set debug breakpoint on' will trigger an
assertion for 'catch' style breakpoints, e.g.:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) catch exec
Catchpoint 1 (exec)
(gdb) set debug breakpoint on
(gdb) start
[breakpoint] dump_condition_tokens: Tokens: { INFERIOR: "1" }
Temporary breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
Starting program: /tmp/hello.x
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
../../gdb-16.1/gdb/gdbarch-gen.c:1764: internal-error: gdbarch_addr_bit: Assertion `gdbarch != NULL' failed.
.... etc ...
The problem is that catch breakpoints don't set the
bp_location::gdbarch member variable, they a "dummy" location added
with a call to add_dummy_location (breakpoint.c).
The breakpoint_location_address_str function (which is only used for
breakpoint debug output) relies on bp_location::gdbarch being set in
order to call the paddress function.
I considered trying to ensure that the bp_location::gdbarch variable
is always set to sane value. For example, in add_dummy_location I
tried copying the gdbarch from the breakpoint object, and this does
work for the catchpoint case, but for some of the watchpoint cases,
even the breakpoint object has no gdbarch value set.
Now this seemed a little suspect, but, the more I thought about it, I
wondered if "fixing" the gdbarch was allowing me to solve the wrong
problem.
If the gdbarch was set, then this would allow us to print the address
field of the bp_location, which is going to be 0, after all, as this
is a dummy location, which has no address.
But does it really make sense to print the address 0? For some
targets, 0 is a valid address. But that wasn't an address we actually
selected, it's just the default value for dummy locations.
And we already have a helper function bl_address_is_meaningful, which
returns false for dummy locations.
So, I propose that in breakpoint_location_address_str, we use
bl_address_is_meaningful to detect dummy locations, and skip the
address printing code in that case.
For testing, I temporarily changed insert_bp_location so that
breakpoint_location_address_str was always called, even when
breakpoint debugging was off. I then ran the whole testsuite.
Without the fixes included in this commit I saw lots of assertion
failures, but with the fixes from this commit in place, I now see no
assertion failures.
I've added a new test which reveals the original assertion failure.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
For some reason, when testing GDB on Cygwin, I get:
child process exited abnormally
while executing
"exec sh -c "exec > /dev/null 2>&1 && (kill -2 -$spid || kill -2 $spid)""
(procedure "close_wait_program" line 20)
invoked from within
"close_wait_program $shell_id $pid"
(procedure "standard_close" line 23)
invoked from within
"standard_close "Windows-ROCm""
("eval" body line 1)
invoked from within
"eval ${try}_${proc} \"$dest\" $args"
(procedure "call_remote" line 42)
invoked from within
"call_remote "" close $host"
(procedure "remote_close" line 3)
invoked from within
"remote_close host"
(procedure "log_and_exit" line 30)
invoked from within
"log_and_exit"
When that happens from within clean_restart, clean_restart doesn't
clear the gdb_spawn_id variable, and then when clean_restart starts up
a new GDB, that sees that gdb_spawn_id is already set, so it doesn't
actually spawn a new GDB, and so clean_restart happens to reuse the
same GDB (!). Many tests happen to actually work OK with this, but
some don't, and the failure modes can be head-scratching.
Of course, the failure to close GDB should be fixed, but when it
happens, I think it's good to not end up with the current weird state.
Connecting the "child process exit abnormally" errors at the end of a
testcase run with weird FAILs in other testcases took me a while (as
in, weeks!), it wasn't obvious to me immediately.
Thus, this patch makes default_gdb_exit more resilient to failed
closes, so that gdb_spawn_id is unset even is closing GDB fails, and
we move on to start a new GDB.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I9ec95aa61872a40095775534743525e0ad2097d2
|
