| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The DWO code in the DWARF reader currently uses objfile::intern. This
accesses a shared data structure and so would be racy when used from
multiple threads. I don't believe this can happen right now, but
background reading could provoke this, and in any case it's better to
avoid this, just to be sure.
This patch changes this code to just use a std::string. A new type is
introduced to do hash table lookups, to avoid unnecessary copies.
|
|
|
|
gdb.base/vfork-follow-parent.exp
When running test-case gdb.base/vfork-follow-parent.exp it passes fine, but
when running it with "taskset -c 0" I run into:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 26606] (vfork-follow-parent-exit)]^M
[Switching to thread 1.1 (process 26606)]^M
(gdb) Reading symbols from vfork-follow-parent-exit...^M
FAIL: $exp: exec_file=vfork-follow-parent-exit: target-non-stop=on: \
non-stop=off: resolution_method=schedule-multiple: inferior 1 (timeout)
...
Fix this by using -no-prompt-anchor.
Tested on x86_64-linux.
PR testsuite/31166
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31166
|
|
On aarch64-linux, with gcc 13.2.1, I run into:
...
(gdb) backtrace^M
#0 break_here () at solib-search.c:30^M
#1 0x0000fffff7f20194 in lib2_func4 () at solib-search-lib2.c:50^M
#2 0x0000fffff7f70194 in lib1_func3 () at solib-search-lib1.c:50^M
#3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
#5 0x00000000004101b4 in main () at solib-search.c:23^M
(gdb) PASS: gdb.base/solib-search.exp: \
backtrace (with wrong libs) (data collection)
FAIL: gdb.base/solib-search.exp: backtrace (with wrong libs)
...
The FAIL is generated by this code in the test-case:
...
if { $expect_fail } {
# If the backtrace output is correct the test isn't sufficiently
# testing what it should.
if { $count == $total_expected } {
set fail 1
}
...
The test-case:
- builds two versions of two shared libs, a "right" and "wrong" version, the
difference being an additional dummy function (called spacer function),
- uses the "right" version to generate a core file,
- uses the "wrong" version to interpret the core file, and
- generates a backtrace.
The intent is that the backtrace is incorrect due to using the "wrong"
version, but actually it's correct. This is because the spacer functions
aren't large enough.
Fix this by increasing the size of the spacer functions by adding a dummy
loop, after which we have, as expected, an incorrect backtrace:
...
(gdb) backtrace^M
#0 break_here () at solib-search.c:30^M
#1 0x0000fffff7f201c0 in ?? ()^M
#2 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
#5 0x00000000004101b4 in main () at solib-search.c:23^M
(gdb) PASS: gdb.base/solib-search.exp: \
backtrace (with wrong libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with wrong libs)
...
Tested on aarch64-linux.
|
|
On aarch64-linux, I run into:
...
FAIL: gdb.base/annota1.exp: backtrace from shlibrary (timeout)
...
due to the PAC marker showing up:
...
^Z^Zframe-address^M
0x000000000041025c [PAC]^M
^Z^Zframe-address-end^M
...
In the docs the marker is documented as follows:
...
When GDB is debugging the AArch64 architecture, and the program is using the
v8.3-A feature Pointer Authentication (PAC), then whenever the link register
$lr is pointing to an PAC function its value will be masked. When GDB prints
a backtrace, any addresses that required unmasking will be postfixed with the
marker [PAC]. When using the MI, this is printed as part of the addr_flags
field.
...
Update the test-case to allow the PAC marker.
Likewise in a few other test-cases.
While we're at it, rewrite the affected pattern pat_begin in annota1.exp into
a more readable form. Likewise for the corresponding pat_end.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/31202
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31202
|
|
This commits changes how errors are reported from the expression
parser. Previously, parser errors were reported like this:
(gdb) p a1 +}= 432
A syntax error in expression, near `}= 432'.
(gdb) p a1 +
A syntax error in expression, near `'.
The first case is fine, a user can figure out what's going wrong, but
the second case is a little confusing; as the error occurred at the
end of the expression GDB just reports the empty string to the user.
After this commit the first case is unchanged, but the second case now
reports like this:
(gdb) p a1 +
A syntax error in expression, near the end of `a1 +'.
Which I think is clearer. There is a possible issue if the expression
being parsed is very long, GDB will repeat the whole expression. But
this issue already exists in the standard case; if the error occurs
early in a long expression GDB will repeat everything after the syntax
error. So I've not worried about this case in my new code either,
which keeps things simpler.
I did consider trying to have multi-line errors here, in the style
that gcc produces, with some kind of '~~~~~^' marker on the second
line to indicate where the error occurred; but I rejected this due to
the places in GDB where we catch an error and repackage the message
within some longer string, I don't think multi-line error messages
would work well in that case. At a minimum it would require some
significant work in order to make all our error handling multi-line
aware.
I've added a couple of extra tests in gdb.base/exprs.exp.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Many (all?) of the expression parsers implement yyerror to handle
parser errors, and all of these functions are basically identical.
This commit adds a new parser_state::parse_error() function, which
implements the common error handling code, this function can then be
called from all the different yyerror functions.
The benefit of this is that (in a future commit) I can improve the
error output, and all the expression parsers will benefit.
This commit is pure refactoring though, and so, there should be no
user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
While working on a later commit in this series I realised that the
error() function doesn't support output styling. Due to the way that
output from error() calls is passed around within the exception
object and often combined with other output, it's not immediately
obvious to me if we should be trying to support styling in this
context or not.
On inspection, I found one place in GDB where we apparently try to
apply styling within the error() output (in procfs.c). I suspect this
error() call might not be tested.
Rather than try to implement styling in the error() output, right now
I'm proposing to just remove the attempt to style error() output.
This doesn't mean that someone shouldn't add error() styling in the
future, but right now, I'm not planning to do that, I just wanted to
fix this in passing.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Currently GDB when executing in reverse over multiple statements in a single
line of source code, GDB stops in the middle of the line. Thus requiring
multiple commands to reach the previous line. GDB should stop at the first
instruction of the line, not in the middle of the line.
The following description of the incorrect behavior was taken from an
earlier message by Pedro Alves <pedro@palves.net>:
https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html
---------------------------------
The source line looks like:
func1 (); func2 ();
in the test case:
(gdb) list 1
1 void func1 ()
2 {
3 }
4
5 void func2 ()
6 {
7 }
8
9 int main ()
10 {
11 func1 (); func2 ();
12 }
compiled with:
$ gcc reverse.c -o reverse -g3 -O0
$ gcc -v
...
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
Now let's debug it with target record, using current gdb git master
(f3d8ae90b236),
$ gdb ~/reverse
GNU gdb (GDB) 14.0.50.20230124-git
...
Reading symbols from /home/pedro/reverse...
(gdb) start
Temporary breakpoint 1 at 0x1147: file reverse.c, line 11.
Starting program: /home/pedro/reverse
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main () at reverse.c:11
11 func1 (); func2 ();
(gdb) record
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
=> 0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
(gdb) n
12 }
So far so good, a "next" stepped over the whole of line 11 and stopped at
line 12.
Let's confirm where we are now:
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
=> 0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
Good, we're at the first instruction of line 12.
Now let's undo the "next", with "reverse-next":
(gdb) reverse-next
11 func1 (); func2 ();
Seemingly stopped at line 11. Let's see exactly where:
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
=> 0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
(gdb)
And lo, we stopped in the middle of line 11! That is a bug, we should have
stepped back all the way to the beginning of the line. The "reverse-next"
should have fully undone the prior "next" command.
--------------------
This patch fixes the incorrect GDB behavior by ensuring that GDB stops at
the first instruction in the line.
The test case gdb.reverse/func-map-to-same-line.exp is added to testsuite
to verify this fix when the line table information is and is not available.
|
|
When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on
the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp.
The failure happens around the following code:
38 b[1] = shr2(17); /* middle part two */
40 b[0] = 6; b[1] = 9; /* generic statement, end part two */
42 shr1 ("message 1\n"); /* shr1 one */
Normal execution:
- step from line 38 will land on line 40.
- step from line 40 will land on line 42.
Reverse execution:
- step from line 42 will land on line 40.
- step from line 40 will land on line 40.
- step from line 40 will land on line 38.
The problem here is that line 40 contains two contiguous but distinct
PC ranges in the line table, like so:
Line 40 - [0x7ec ~ 0x7f4]
Line 40 - [0x7f4 ~ 0x7fc]
The two distinct ranges are generated because GCC started outputting source
column information, which GDB doesn't take into account at the moment.
When stepping forward from line 40, we skip both of these ranges and land on
line 42. When stepping backward from line 42, we stop at the start PC of the
second (or first, going backwards) range of line 40.
Since we've reached ecs->event_thread->control.step_range_start, we stop
stepping backwards.
The above issues were fixed by introducing a new function that looks for
adjacent PC ranges for the same line, until we notice a line change. Then
we take that as the start PC of the range. The new start PC for the range
is used for the control.step_range_start when setting up a step range.
The test case gdb.reverse/map-to-same-line.exp is added to test the fix
for the above reverse step issues.
Patch has been tested on PowerPC, X86 and AArch64 with no regressions.
|
|
This patch adds two new options to gdb_compile to specify if the compile
should or should not generate the line table information. The
options are supported on clang and gcc version 7 and newer.
Patch has been tested on PowerPC with both gcc and clang.
|
|
This commit adds a mechanism for GDB to detect the linetable opcode
DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
that a certain instruction marks the point where the frame is destroyed.
While the standard allows for multiple points marked with epilogue_begin
in the same function, for performance reasons, the function that
searches for the epilogue address will only find the last address that
sets this flag for a given block.
This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
use the epilogue begin directly, and only if an epilogue can't be found
will it attempt heuristics based on the current instruction.
Finally, this commit also changes the dwarf assembler to be able to emit
epilogue-begin instructions, to make it easier to test this patch
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Mark pointed out that a recent patch of mine caused the buildbot to
complain about the formatting of some Python test code. This patch
re-runs 'black' to fix the problem.
|
|
On aarch64-linux with a gdb build without libexpat, I run into:
...
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
catch syscall 59
continue
Continuing.
Catchpoint 5 (call to syscall 59), 0x0000fffff7e04578 in pipe () from \
/lib64/libc.so.6
(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
...
In the test-case, this pattern handles either the syscall name or number for
the pipe syscall:
...
-re -wrap "Catchpoint $decimal \\(call to syscall (pipe|$SYS_pipe)\\).*" {
...
but the pattern for the pipe2 syscall mistakenly uses SYS_pipe instead of
SYS_pipe2:
...
-re -wrap "Catchpoint $decimal \\(call to syscall (pipe2|$SYS_pipe)\\).*" {
...
and consequently doesn't handle the pipe2 syscall number.
Fix the typo by using SYS_pipe2 instead.
Tested on aarch64-linux.
|
|
The gdb docs promise that methods with more than two or more arguments
will accept keywords. However, I found that TuiWindow.write didn't
allow them. This patch adds the missing support.
|
|
When running test-case gdb.base/gdb-index-err.exp in a container as root user,
I run into:
...
FAIL: gdb.base/gdb-index-err.exp: flag=: \
try to write index to a non-writable directory
FAIL: gdb.base/gdb-index-err.exp: flag=-dwarf-5: \
try to write index to a non-writable directory
...
The test-case creates a directory without write permissions:
...
$ ls -ald private
dr-xr-xr-x 2 root root 4096 Dec 29 06:26 private/
...
but apparently the root user is still able to write in it.
Fix this by making the test unsupported for the root user.
Tested on x86_64-linux.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
PR testsuite/31197
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31197
|
|
There will be another update in January.
|
|
Fortran provides additional entry points for subroutines and functions.
These entry points may use only a subset (or a different set) of the
parameters of the original subroutine. The entry points may be described
via the DWARF tag DW_TAG_entry_point.
This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
Currently, between ifx/ifort/gfortran, only ifort is actually emitting
this tag. Both, ifx and gfortran use the DW_TAG_subprogram tag as
workaround/alternative. Thus, this patch really only adds more ifort
support. Even so, some of the attached tests still fail for ifort, due
to some wrong line info generated for the entry points in ifort.
After this patch it is possible to set a breakpoint in gdb with the
ifort compiled example at the entry points 'foo' and 'foobar', which was not
possible before.
As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
which uses some underlying c compiled code and adds some Fortran style DWARF
to it emitting the DW_TAG_entry_point. Before this patch it was not
possible to actually define breakpoint at the entry point tags.
For gfortran there actually exists a bug on bugzilla, asking for the use
of DW_TAG_entry_point over DW_TAG_subprogram:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134
This patch was originally posted here
https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html
but its review/pinging got lost after a while. I reworked it to fit the
current GDB.
Co-authored-by: Bernhard Heckel <bernhard.heckel@intel.com>
Co-authored-by: Tim Wiederhake <tim.wiederhake@intel.com>
Approved-by: Tom Tromey <tom@tromey.com>
|
|
In dwarf2_get_pc_bounds we were writing unchecked to *lowpc. This
commit adds a gdb_assert to first check that lowpc != nullptr.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
This commit is in preparation of the next commit. There, we will add
a second variation to retrieve the pc bounds for DIEs tagged with
DW_TAG_entry_point. Instead of dwarf_get_pc_bounds_ranges_or_highlow_pc
we will call a separate method for entry points. As the validity checks
at the endo f dwarf2_get_pc_bounds are the same for both variants,
we introduced the new dwarf_get_pc_bounds_ranges_or_highlow_pc method,
outsourcing part of dwarf2_get_pc_bounds.
This commit should have no functional impact on GDB.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
Some spots loop on the frame chain to find the first next non-inline
frame, and pass that as the "next frame" to
value::allocate_register_lazy / value::allocate_register. This is
necessary if the value is used in the process of computing the id of
"this frame". If the frame next to "this frame" is inlined into "this
frame", then you that next frame won't have a computed id yet. You have
to go past that to find the next non-inline frame, which will have a
computed id.
In other cases, it's fine to store the id of an inline frame as the
"next frame id" in a register struct value. When trying to unwind a
register from it, it will just call inline_frame_prev_register, which
will forward the request to the next next frame, until we hit the next
physical frame.
I think it would make things simpler to just never store the id of an
inline frame as the next frame id of register struct values, and go with
the first next non-inline frame directly. This way, we don't have to
wonder which code paths have to skip inline frames when creating
register values and which don't.
So, change value::allocate_register_lazy to do that work, and remove the
loops for the callers that did it.
Change-Id: Ic88115dac49dc14e3053c95f92050062b24b7310
|
|
Remove VALUE_REGNUM, replace it with a method on struct value. Set
`m_location.reg.regnum` directly from value::allocate_register_lazy,
which is fine because allocate_register_lazy is a static creation
function for struct value.
Change-Id: Id632502357da971617d9dce1e2eab9b56dbcf52d
|
|
Remove VALUE_NEXT_FRAME_ID, replace it with a method on struct value. Set
`m_location.reg.next_frame_id` directly from value::allocate_register_lazy,
which is fine because allocate_register_lazy is a static creation
function for struct value.
Change-Id: Ic9f0f239c166a88dccfee836f9f51871e67548e6
|
|
As explained in the comment removed by the previous commit "gdb: pass
non-nullptr frame to gdbarch_value_from_register in
address_from_register", address_from_register copies some implementation
bits from value_from_register:
/* This routine may be called during early unwinding, at a time
where the ID of FRAME is not yet known. Calling value_from_register
would therefore abort in get_frame_id. However, since we only need
a temporary value that is never used as lvalue, we actually do not
really need to set its VALUE_NEXT_FRAME_ID. Therefore, we re-implement
the core of value_from_register, but use the null_frame_id. */
This is no longer relevant, since we now create a value with a valid next
frame id, so change address_from_register to use value_from_register.
Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43
|
|
By now, all register struct values should have a valid next frame id
(assuming they are created using value::allocate_register or
value::allocate_register_lazy), so there should be no need to pass a
frame alongside the value to read_frame_register_value. Remove the
frame parameter and adjust read_frame_register_value accordingly.
While at it, make read_frame_register_value static, it's only used in
findvar.c.
Change-Id: I118959ef8c628499297c67810916e8ba9934bfac
|
|
value::allocate_register_lazy
Some places that create register struct values don't use register_type
to obtain the value type. This prevents them from using the current
version of value::allocate_register. One spot (value_of_register_lazy)
also creates a lazy register value.
Add a value::allocate_register_lazy method. Add some type parameters
to value::allocate_register and value::allocate_register_lazy, to let
the caller specify the type to use for the value. The parameters
default to nullptr, in which case we use register_type to obtain the
type.
Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec
|
|
address_from_register
address_from_register used to pass null_frame_id to
gdbarch_value_from_register as "this frame"'s id, because it's possible
for it to be called during unwind, when "this frame"'s id is not yet
known. This create an oddity where those register struct values are
created without a valid next frame id. I would much prefer for things
to be consistent and have all register struct values to have a valid
next frame id.
Since gdbarch_value_from_register takes a frame_info_ptr now, rather
than a frame_id, we can pass down "this frame", even if it doesn't have
a valid id. gdbarch_value_from_register implementations can obtain the
next frame from it.
However, it's possible for the "this frame"'s next frame to be an
inline frame, inlined in "this frame", in which case that next frame's
id is also not known. So, loop until we get to the next non-inline
frame (which is actually the frame where registers for "this frame" are
unwound from). This is the same thing that we do in
value_of_register_lazy, for the same reason. A later patch will factor
out this "while next frame is inline" loop to apply it to all register
struct values, so this is somewhat temporary.
Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078
|
|
Pass a frame_info_ptr rather than a frame_id. This avoids having to do
a frame lookup on the callee side, when we can just pass the frame down
directly.
I think this fixes a bug in rs6000-tdep.c where the id of the wrong
frame was set to `VALUE_NEXT_FRAME_ID (v)`.
Change-Id: I77039bc87ea8fc5262f16d0e1446515efa21c565
|
|
I don't think that setting the next frame id is needed there, all code
paths in cooked_read_value do set it properly, AFAIK.
Change-Id: Idb9d9e6f89c2c95c5ebfeec2a63fde89ed84cf3d
|
|
This changes the test suite to look for rogue DAP exceptions in the
log file, and issue a "fail" if one is found.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
I noticed that the DAP attach test case (and similarly
remoted-dap.exp) had a rogue exception stack trace in the log. It
turns out that an attach will generate a stop that does not have a
reason.
This patch fixes the problem in the _on_stop event listener by making
it a bit more careful when examining the event reason. It also adds
some machinery so that attach stops can be suppressed, which I think
is the right thing to do.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This adds a new parameter to control the DAP logging level. By
default, "expected" exceptions are not logged, but the parameter lets
the user change this when more logging is desired.
This also changes a couple of spots to avoid logging the stack trace
for a DAPException.
This patch also documents the existing DAP logging parameter. I
forgot to document this before.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This introduces a new DAPException class, and then changes various
spots in the DAP implementation to wrap "expected" exceptions in this.
This class will help detect rogue exceptions caused by bugs in the
implementation.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
In 2023-12-14 "gdb: make get_frame_register_bytes take the next frame"
(9fc79b42369), *_register_to_value functions were made to (a) call
get_next_frame_sentinel_okay (frame) (b) pass that next frame to
get_frame_register_bytes.
Step (b) was omitted for rs6000-tdep.c; this manifests as a regression on
PPC platforms for e.g. O2_float_param: instead of seeing…
Temporary breakpoint 1, callee.increment (val=val@entry=99.0, msg=...) at callee.adb:19
… we get "optimized_out" for val. Passing next_frame to
get_frame_register_bytes fixes the issue.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In many cases, it's not possible for gdb to discover the executable
when a DAP 'attach' request is used. This patch lets the IDE supply
this information.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
The project has been using Tested-By (tb), Reviewed-By (rb) and
Approved-By (ab) for some time, but there has been no information to be
found in the actual repository. This commit changes that by adding
information about all git trailers to the MAINTAINERS file, so that it
can be easily double-checked. Simply put, the trailers in use work as
follows:
* Tested-by: The person tested the patch and it fixes the problem, or
introduces no regressions (or both).
* Acked-by: The general outline looks good, but the maintainer hasn't
looked at the code
* Reviewed-by: The code looks good, but the reviewer has not approved
the patch to go upstream
* Approved-by: The patch is ready to be pushed to master
These last 3 trailers can also be restricted to one or more areas of GDB
by adding the areas in a comma separated list in parenthesis after the
trailers.
Finally, for completeness sake, the trailers Co-Authored-By and Bug
were added, even though they have been in use for a long time already
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
The TUI status window is called the "locator" in the source, but
"status" in the documentation. Whenever I've needed to find the code,
I've had to search to "locate" it (ha, ha). This patch renames the
window to match the public name of the window.
|
|
The TUI status line is called the "status" window in the
documentation, but not in the source. There, the relevant files are
named "tui-stack", which to me makes it sound like they have something
to do with backtraces. This patch renames them to "tui-status".
|
|
Commit d5cebea18e7a ("Make cached_reg_t own its data") added a
destructor to cached_reg_t.
That caused a build problem with Clang, which errors out like so:
> CXX python/py-unwind.o
> gdb/python/py-unwind.c:126:16: error: flexible array member 'reg' of type 'cached_reg_t[]' with non-trivial destruction
> 126 | cached_reg_t reg[];
> | ^
This is is not really a problem for our code, which allocates the
whole structure with xmalloc, and then initializes the array elements
with in-place new, and then takes care to call the destructor
manually. Like, commit d5cebea18e7a did:
@@ -928,7 +927,7 @@ pyuw_dealloc_cache (frame_info *this_frame, void *cache)
cached_frame_info *cached_frame = (cached_frame_info *) cache;
for (int i = 0; i < cached_frame->reg_count; i++)
- xfree (cached_frame->reg[i].data);
+ cached_frame->reg[i].~cached_reg_t ();
Maybe we should get rid of the flexible array member and use a bog
standard std::vector. I doubt this would cause any visible
performance issue.
Meanwhile, to unbreak the build, this commit switches from C99-style
flexible array member to 0-length array. It behaves the same, and
Clang doesn't complain. I got the idea from here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932#c11
GCC 9, our oldest support version, already supported this:
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Zero-Length.html
but the extension is actually much older than that. Note that
C99-style flexible array members are not standard C++ either.
Change-Id: I37dda18f367e238a41d610619935b2a0f2acacce
|
|
Downstream, AMD is carrying a testcase
(gdb.rocm/continue-over-kernel-exit.exp) that exposes a couple issues
with the amd-dbgapi target's handling of exited threads. The test
can't be added upstream yet, unfortunately, due to dependency on DWARF
extensions that can't be upstreamed yet. However, it can be found on
the mailing list on the same series as this patch.
The test spawns a kernel with a number of waves. The waves do nothing
but exit. There is a breakpoint on the s_endpgm instruction. Once
that breakpoint is hit, the test issues a "continue" command. We
should see one breakpoint hit per wave, and then the whole program
exiting. We do see that, however we also see this:
[New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
[AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
*repeat for other waves*
...
[Thread 0x7ffff626f640 (LWP 3048491) exited]
[Thread 0x7fffeb7ff640 (LWP 3048488) exited]
[Inferior 1 (process 3048475) exited normally]
That "New AMDGPU Wave" output comes from infrun.c itself adding the
thread to the GDB thread list, because it got an event for a thread
not on the thread list yet. The output shows "?"s instead of proper
coordinates, because the event was a TARGET_WAITKIND_THREAD_EXITED,
i.e., the wave was already gone when infrun.c added the thread to the
thread list.
That shouldn't ever happen for the amd-dbgapi target, threads should
only ever be added by the backend.
Note "New AMDGPU Wave ?:?:?:1" is for wave 1. What happened was that
wave 1 terminated previously, and a previous call to
amd_dbgapi_target::update_thread_list() noticed the wave had vanished
and removed it from the GDB thread list. However, because the wave
was stepping when it terminated (due to the displaced step over the
s_endpgm) instruction, it is guaranteed that the amd-dbgapi library
queues a WAVE_COMMAND_TERMINATED event for the exit.
When we process that WAVE_COMMAND_TERMINATED event, in
amd-dbgapi-target.c:process_one_event, we return it to the core as a
TARGET_WAITKIND_THREAD_EXITED event:
static void
process_one_event (amd_dbgapi_event_id_t event_id,
amd_dbgapi_event_kind_t event_kind)
{
...
if (status == AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID
&& event_kind == AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED)
ws.set_thread_exited (0);
...
}
Recall the wave is already gone from the GDB thread list. So when GDB
sees that TARGET_WAITKIND_THREAD_EXITED event for a thread it doesn't
know about, it adds the thread to the thread list, resulting in that:
[New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
and then, because it was a TARGET_WAITKIND_THREAD_EXITED event, GDB
marks the thread exited right afterwards:
[AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
The fix is to make amd_dbgapi_target::update_thread_list() _not_
delete vanishing waves iff they were stepping or in progress of being
stopped. These two cases are the ones dbgapi guarantees will result
in a WAVE_COMMAND_TERMINATED event if the wave terminates:
/**
* A command for a wave was not able to complete because the wave has
* terminated.
*
* Commands that can result in this event are ::amd_dbgapi_wave_stop and
* ::amd_dbgapi_wave_resume in single step mode. Since the wave terminated
* before stopping, this event will be reported instead of
* ::AMD_DBGAPI_EVENT_KIND_WAVE_STOP.
*
* The wave that terminated is available by the ::AMD_DBGAPI_EVENT_INFO_WAVE
* query. However, the wave will be invalid since it has already terminated.
* It is the client's responsibility to know what command was being performed
* and was unable to complete due to the wave terminating.
*/
AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED = 2,
As the comment says, it's GDB's responsability to know whether the
wave was stepping or being stopped. Since we now have a wave_info map
with one entry for each wave, that seems like the place to store that
information. However, I still decided to put all the coordinate
information in its own structure. I.e., basically renamed the
existing wave_info to wave_coordinates, and then added a new wave_info
structure that holds the new state, plus a wave_coordinates object.
This seemed cleaner as there are places where we only need to
instantiate a wave_coordinates object.
There's an extra twist. The testcase also exercises stopping at a new
kernel right after the first kernel fully exits. In that scenario, we
were hitting this assertion after the first kernel fully exits and the
hit of the breakpoint at the second kernel is handled:
[amd-dbgapi] process_event_queue: Pulled event from dbgapi: event_id.handle = 26, event_kind = WAVE_STOP
[amd-dbgapi-lib] suspending queue_3, queue_2, queue_1 (refresh wave list)
../../src/gdb/amd-dbgapi-target.c:1625: internal-error: amd_dbgapi_thread_deleted: Assertion `it != info->wave_info_map.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
This is the exact same problem as above, just a different
manifestation. In this scenario, we end up in update_thread_list
successfully deleting the exited thread (because it was no longer the
current thread) that was incorrectly added by infrun.c. Because it
was added by infrun.c and not by amd-dbgapi-target.c:add_gpu_thread,
it doesn't have an entry in the wave_info map, so
amd_dbgapi_thread_deleted trips on this assertion:
gdb_assert (it != info->wave_info_map.end ());
here:
...
-> stop_all_threads
-> update_thread_list
-> target_update_thread_list
-> amd_dbgapi_target::update_thread_list
-> thread_db_target::update_thread_list
-> linux_nat_target::update_thread_list
-> delete_exited_threads
-> delete_thread
-> delete_thread_1
-> gdb::observers::observable<thread_info*>::notify
-> amd_dbgapi_thread_deleted
-> internal_error_loc
The testcase thus tries both running to exit after the first kernel
exits, and running to a breakpoint in a second kernel after the first
kernel exits.
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I43a66f060c35aad1fe0d9ff022ce2afd0537f028
|
|
Currently, if you step over kernel exit, you see:
stepi
[AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
Command aborted, thread exited.
(gdb)
Those '?' are because the thread/wave is already gone by the time GDB
prints the "exited" notification, we can't ask dbgapi for any info
about the wave anymore.
This commit fixes it by caching the wave's coordinates as soon as GDB
sees the wave for the first time, and making
amd_dbgapi_target::pid_to_str use the cached info.
At first I thought of clearing the wave_info object from a
thread_exited observer. However, that is too soon, resulting in this:
(gdb) si
[AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
Command aborted, thread exited.
(gdb) thread
[Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)]
We need instead to clear the wave info when the thread is ultimately
deleted, so we get:
(gdb) si
[AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
Command aborted, thread exited.
(gdb) thread
[Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)]
And for that, we need a new thread_deleted observable.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580
|
|
With AMD GPU debugging, I noticed that when stepping over a breakpoint
placed on top of the s_endpgm instruction inline (displaced=off), GDB
would behave differently -- it wouldn't print the wave exit. E.g:
With displaced stepping, or no breakpoint at all:
stepi
[AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
Command aborted, thread exited.
(gdb)
With inline stepping:
stepi
Command aborted, thread exited.
(gdb)
In the cases we see the "exited" notification, handle_thread_exit is
what first called delete_thread on the exiting thread, which is
non-silent.
With inline stepping, however, handle_thread_exit ends up in
update_thread_list (via restart_threads) before any delete_thread
call. Thus, amd_dbgapi_target::update_thread_list notices that the
wave is gone and deletes it with delete_thread_silent.
This commit fixes it, by making handle_thread_exited call
set_thread_exited (with the default silent=false) early, which emits
the user-visible notification.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I22ab3145e18d07c99dace45576307b9f9d5d966f
|
|
displaced_step_finish can be called with event_status.kind ==
TARGET_WAITKIND_THREAD_EXITED, and in that case it is not possible to
get at the already-exited thread's registers.
This patch moves the get_thread_regcache calls to branches that
actually need it, where we know the thread is still alive.
It also adds an assertion to get_thread_regcache, to help catching
these broken cases sooner.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I63b5eacb3e02a538fc5087c270d8025adfda88c3
|
|
While making step over thread exit work properly on AMDGPU, I noticed
that if there's a breakpoint on top of the exit syscall, and,
displaced stepping is off, then when GDB reports "Command aborted,
thread exited.", GDB also switches focus to a random thread, instead
of leaving the exited thread as selected:
(gdb) thread
[Current thread is 6, lane 0 (AMDGPU Lane 1:4:1:1/0 (0,0,0)[0,0,0])]
(gdb) si
Command aborted, thread exited.
(gdb) thread
[Current thread is 5 (Thread 0x7ffff626f640 (LWP 3248392))]
(gdb)
The previous patch extended gdb.threads/step-over-thread-exit.exp to
exercise this on GNU/Linux (on the CPU side), and there, after that
"si", we always end up with the exiting thread as selected even
without this fix, but that's just a concidence, there's a code path
that happens to select the exiting thread for an unrelated reason.
This commit add the explict switch, fixing the latent problem for
GNU/Linux, and the actual problem on AMDGPU. I wrote a gdb.rocm/
testcase for this, but it can't be upstreamed yet, until more pieces
of the DWARF machinery are upstream as well.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I6ff57a79514ac0142bba35c749fe83d53d9e4e51
|
|
This commit makes the following improvements to
gdb.threads/step-over-thread-exit.exp:
- Add a third axis to stepping over the breakpoint with displaced vs
inline stepping -- also test with no breakpoint at all.
- Check that when GDB reports "Command aborted, thread exited.", the
selected thread is the thread that exited. This is always true
currently on GNU/Linux by coincidence, but a similar testcase on AMD
GPU exposed a problem here. Better make the testcase catch any
potential regression.
- Fixes a race that Simon ran into with GDBserver testing.
(gdb) next
[New Thread 2143071.2143438]
Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74
74 SYSCALL (my_exit, __NR_exit)
(gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits
I was not able to reproduce it, but I believe that what happens is
the following:
Once we continue, the thread 2 exits, and the main thread thus
unblocks from its pthread_join, and spawns a new thread. That new
thread may hit the breakpoint at my_exit_syscall very quickly. GDB
could then see/process that breakpoint event before the thread exit
event for the thread we care about, which would result in the
failure seen above.
The fix here is to not loop and start a new thread at all in the
scenario where the race can happen. We only need to loop and spawn
new threads when testing with "cmd=continue" and schedlock off, in
which case GDB doesn't abort the command when the thread exits.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I90c95c32f00630a3f682b1541c23aff52451f9b6
|
|
By inspection, I noticed that the previous patch went too far, here:
@@ -7705,7 +7713,8 @@ remote_target::discard_pending_stop_replies (struct inferior *inf)
if (rs->remote_desc == NULL)
return;
- reply = (struct stop_reply *) rns->pending_event[notif_client_stop.id];
+ stop_reply_up reply
+ = as_stop_reply_up (std::move (rns->pending_event[notif_client_stop.id]));
/* Discard the in-flight notification. */
if (reply != NULL && reply->ptid.pid () == inf->pid)
That is always moving the stop reply from pending_event, when we only
really want to peek into it. The code further below that even says:
/* Discard the in-flight notification. */
if (reply != NULL && reply->ptid.pid () == inf->pid)
{
/* Leave the notification pending, since the server expects that
we acknowledge it with vStopped. But clear its contents, so
that later on when we acknowledge it, we also discard it. */
This commit reverts that hunk back, adjusted to use unique_ptr::get().
Change-Id: Ifc809d1a8225150a4656889f056d51267100ee24
|
|
We already use unique_ptr with notif_event and stop_reply in some
places around the remote target, but not fully. There are several
code paths that still use raw pointers. This commit makes all of the
ownership of these objects tracked by unique pointers, making the
lifetime flow much more obvious, IMHO.
I notice that it fixes a leak -- in remote_notif_stop_ack, We weren't
destroying the stop_reply object if it was of TARGET_WAITKIND_IGNORE
kind.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Id81daf39653d8792c8795b2a145772176bfae77c
|
|
struct cached_reg_t owns its data buffer, but currently that is
managed manually. Convert it to use a unique_xmalloc_ptr.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I05a107098b717299e76de76aaba00d7fbaeac77b
|
|
tdesc_data is not part of a union, since commit 4f3681cc3361 ("Fix thread's
gdbarch when SVE vector length changes"). Remove the stale comment and
constructor.
Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503
|
|
pseudo_to_concat_raw
Here, we write single complete registers, we don't need the
functionality of put_frame_register_bytes, use put_frame_register
instead.
Change-Id: I987867a27249db4f792a694b47ecb21c44f64d08
Approved-By: Tom Tromey <tom@tromey.com>
|
