| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A co-worker pointed out that gdb's DAP implementation might return an
integer for the name of a stack frame, like:
{"id": 1, "name": 93824992310799, ...}
This can be seen currently in the logs of the bt-nodebug.exp test
case.
What is happening is that FrameDecorator falls back on returning the
PC when the frame's function symbol cannot be found, relying on the
gdb core to look up the minsym and print its name.
This can actually yield the wrong answer sometimes, because it falls
into the get_frame_pc / get_frame_address_in_block problem -- if the
frame is at a call to a noreturn function, the PC in this case might
appear to be in the next function in memory. For more on this, see:
https://sourceware.org/bugzilla/show_bug.cgi?id=8416
and related bugs.
However, there's a different approach we can take: the code here can
simply use Frame.name. This handles the PC problem correctly, and
gets us the information we need.
|
|
This commit replaces this earlier commit:
commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b
Date: Fri Oct 14 14:53:15 2022 +0100
gdb: don't always print breakpoint location after failed condition check
and is a result of feedback received here[1].
The original commit addressed a problem where, if a breakpoint
condition included an inferior function call, and if the inferior
function call failed, then GDB would announce the stop twice. Here's
an example of GDB's output before the above commit that shows the
problem being addressed:
(gdb) break foo if (some_func ())
Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
(gdb) r
Starting program: /tmp/bpcond
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in some_func () at bpcond.c:5
5 return *p;
Error in testing condition for breakpoint 1:
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(some_func) will be abandoned.
When the function is done executing, GDB will silently stop.
Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
5 return *p;
(gdb)
The original commit addressed this issue in breakpoint.c, by spotting
that the $pc had changed while evaluating the breakpoint condition,
and inferring from this that GDB must have stopped elsewhere.
However, the way in which the original commit suppressed the second
stop announcement was to set bpstat::print to true -- this tells GDB
not to print the frame during the stop announcement, and for the CLI
this is fine, however, it was pointed out that for the MI this still
isn't really enough. Below is an example from an MI session after the
above commit was applied, this shows the problem with the above
commit:
-break-insert -c "cond_fail()" foo
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="0",original-location="foo"}
(gdb)
-exec-run
=thread-group-started,id="i1",pid="2636270"
=thread-created,id="1",group-id="i1"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}]
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/libm.so.6",target-name="/lib64/libm.so.6",host-name="/lib64/libm.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7e59390",to="0x00007ffff7ef4f98"}]
=library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7ca66b0",to="0x00007ffff7df3c5f"}]
~"\nProgram"
~" received signal SIGSEGV, Segmentation fault.\n"
~"0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24\n"
~"24\t return *p;\t\t\t/* Crash here. */\n"
*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x0000000000401116",func="cond_fail",args=[],file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="24",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9"
&"Error in testing condition for breakpoint 1:\n"
&"The program being debugged was signaled while in a function called from GDB.\n"
&"GDB remains in the frame where the signal was received.\n"
&"To change this behavior use \"set unwindonsignal on\".\n"
&"Evaluation of the expression containing the function\n"
&"(cond_fail) will be abandoned.\n"
&"When the function is done executing, GDB will silently stop.\n"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="1",original-location="foo"}
*stopped
(gdb)
Notice that we still see two '*stopped' lines, the first includes the
full frame information, while the second has no frame information,
this is a result of bpstat::print having been set. Ideally, the
second '*stopped' line should not be present.
By setting bpstat::print I was addressing the problem too late, this
flag really only changes how interp::on_normal_stop prints the stop
event, and interp::on_normal_stop is called (indirectly) from the
normal_stop function in infrun.c. A better solution is to avoid
calling normal_stop at all for the stops which should not be reported
to the user, and this is what I do in this commit.
This commit has 3 parts:
1. In breakpoint.c, revert the above commit,
2. In fetch_inferior_event (infrun.c), capture the stop-id before
calling handle_inferior_event. If, after calling
handle_inferior_event, the stop-id has changed, then this indicates
that somewhere within handle_inferior_event, a stop was announced to
the user. If this is the case then GDB should not call normal_stop,
and we should rely on whoever announced the stop to ensure that we
are in a PROMPT_NEEDED state, which means the prompt will be
displayed once fetch_inferior_event returns. And,
3. In infcall.c, do two things:
(a) In run_inferior_call, after making the inferior call, ensure
that either async_disable_stdin or async_enable_stdin is called
to put the prompt state, and stdin handling into the correct
state based on whether the inferior call completed successfully
or not, and
(b) In call_thread_fsm::should_stop, call async_enable_stdin
rather than changing the prompt state directly. This isn't
strictly necessary, but helped me understand this code more.
This async_enable_stdin call is only reached if normal_stop is
not going to be called, and replaces the async_enable_stdin call
that exists in normal_stop. Though we could just adjust the
prompt state if felt (to me) much easier to understand when I
could see this call and the corresponding call in normal_stop.
With these changes in place now, when the inferior call (from the
breakpoint condition) fails, infcall.c leaves the prompt state as
PROMPT_NEEDED, and leaves stdin registered with the event loop.
Back in fetch_inferior_event GDB notices that the stop-id has changed
and so avoids calling normal_stop.
And on return from fetch_inferior_event GDB will display the prompt
and handle input from stdin.
As normal_stop is not called the MI problem is solved, and the test
added in the earlier mentioned commit still passes just fine, so the
CLI has not regressed.
[1] https://inbox.sourceware.org/gdb-patches/6fd4aa13-6003-2563-5841-e80d5a55d59e@palves.net/
|
|
DAP requires python module typing, which is supported starting python 3.5.
Make this formal by:
- disabling the dap interpreter for python version < 3.5
- returning 0 in allow_dap_tests for python version < 3.5
Approved-By: Tom Tromey <tom@tromey.com>
PR dap/30708
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30708
|
|
Tom de Vries pointed out that my recent change to fixed_points.exp
failed with older versions of GCC. This patch fixes the problem by
skipping the new test in this situation.
|
|
This implements the DAP "source" request. I renamed the
"loadedSources" function from "sources" to "loaded_sources" to avoid
any confusion. I also moved the loadedSources test to the new
sources.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30691
|
|
This patch implements ValueFormat for DAP. Currently this only means
supporting "hex".
Note that StackFrameFormat is defined to have many more options, but
none are currently recognized. It isn't entirely clear how these
should be handled. I'll file a new gdb bug for this, and perhaps an
upstream DAP bug as well.
New in v2:
- I realized that the "hover" context was broken, and furthermore
that we only had tests for "hover" failing, not for it succeeding.
This version fixes the oversight and adds a test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30469
|
|
I noticed that the support for memoryReference in the "variables"
output is gated on the client "supportsMemoryReferences" capability.
This patch implements this and makes some other changes to the DAP
memory reference code:
* Remove the memoryReference special case from _SetResult.
Upstream DAP fixed this oversight in response to
https://github.com/microsoft/debug-adapter-protocol/issues/414
* Don't use the address of a variable as its memoryReference -- only
emit this for pointer types. There's no spec support for the
previous approach.
* Use strip_typedefs to handle typedefs of pointers.
|
|
This adds DAP support for the various C++ exception-catching
operations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30682
|
|
This implements the DAP 'terminated' event. Vladimir Makaev noticed
that VSCode will not report the debug session as over unless this is
sent.
It's not completely clear when exactly this event ought to be sent.
Here I've done it when the inferior exits.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30681
|
|
When the DAP client sets a breakpoint, gdb currently sends a "new
breakpoint" event. However, Vladimir Makaev discovered that this
causes VSCode to think there are two breakpoints.
This patch changes gdb to suppress the event in this case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30678
|
|
This adds the "cwd" parameter to the DAP launch request.
This came up here:
https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/issues/90
... and seemed like a good idea.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This patch refactors dap_launch to make it more extensible and also
easier to use.
|
|
I build gdb with -fsanitize=thread and ran the testsuite, and ran into the
case that a race is detected, but we see the full stack trace only for one of
the two accesses, and the other one is showing "failed to restore the stack".
Try to prevent this by setting ThreadSanitizer flag history_size [1] to the
maximum (7) by default, as suggested here [2].
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags
[2] https://groups.google.com/g/thread-sanitizer/c/VzSWE7UxhIE
|
|
Alexandre Oliva found a bug in gdb's handling of fixed-point -- a
certain Ada fixed-point type would be misintepreted. The bug was that
the DW_AT_small looked like:
<1><13cd>: Abbrev Number: 16 (DW_TAG_constant)
<13ce> DW_AT_GNU_numerator: 1
<13cf> DW_AT_GNU_denominator: 0x8000000000000000
... but gdb interpreted the denominator as a negative value.
|
|
When debugging a multi-process application where a parent spawns
multiple child processes using the ROCm runtime, I see the following
assertion failure:
../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x556e9a318540 gdb_internal_backtrace_1
../../gdb/bt-utils.c:122
0x556e9a318540 _Z22gdb_internal_backtracev
../../gdb/bt-utils.c:168
0x556e9a730224 internal_vproblem
../../gdb/utils.c:396
0x556e9a7304e0 _Z15internal_verrorPKciS0_P13__va_list_tag
../../gdb/utils.c:476
0x556e9a87aeb4 _Z18internal_error_locPKciS0_z
../../gdbsupport/errors.cc:58
0x556e9a29f446 process_one_event
../../gdb/amd-dbgapi-target.c:1071
0x556e9a29f446 process_event_queue
../../gdb/amd-dbgapi-target.c:1156
0x556e9a29faf2 _ZN17amd_dbgapi_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../gdb/amd-dbgapi-target.c:1262
0x556e9a6b0965 _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../gdb/target.c:2586
0x556e9a4c221f do_target_wait_1
../../gdb/infrun.c:3876
0x556e9a4d8489 operator()
../../gdb/infrun.c:3935
0x556e9a4d8489 do_target_wait
../../gdb/infrun.c:3964
0x556e9a4d8489 _Z20fetch_inferior_eventv
../../gdb/infrun.c:4365
0x556e9a87b915 gdb_wait_for_event
../../gdbsupport/event-loop.cc:694
0x556e9a87c3a9 gdb_wait_for_event
../../gdbsupport/event-loop.cc:593
0x556e9a87c3a9 _Z16gdb_do_one_eventi
../../gdbsupport/event-loop.cc:217
0x556e9a521689 start_event_loop
../../gdb/main.c:412
0x556e9a521689 captured_command_loop
../../gdb/main.c:476
0x556e9a523c04 captured_main
../../gdb/main.c:1320
0x556e9a523c04 _Z8gdb_mainP18captured_main_args
../../gdb/main.c:1339
0x556e9a24b1bf main
../../gdb/gdb.c:32
---------------------
../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
A problem internal to GDB has been detected,
Before diving into why this error appears, let's explore how things are
expected to work in normal circumstances. When a process being debugged
starts using the ROCm runtime, the following happens:
- The runtime registers itself to the driver.
- The driver creates a "runtime loaded" event and notifies the debugger
that a new event is available by writing to a file descriptor which is
registered in GDB's main event loop.
- GDB core calls the callback associated with this file descriptor
(dbgapi_notifier_handler). Because the amd-dbgapi-target is not
pushed at this point, the handler pulls the "runtime loaded" event
from the driver (this is the only event which can be available at this
point) and eventually pushes the amd-dbgapi-target on the inferior's
target stack.
In a nutshell, this is the expected AMDGPU runtime activation process.
From there, when new events are available regarding the GPU threads, the
same file descriptor is written to. The callback sees that the
amd-dbgapi-target is pushed so marks the amd_dbgapi_async_event_handler.
This will later cause amd_dbgapi_target::wait to be called. The wait
method pulls all the available events from the driver and handles them.
The wait method returns the information conveyed by the first event, the
other events are cached for later calls of the wait method.
Note that because we are under the wait method, we know that the
amd-dbgapi-target is pushed on the inferior target stack. This implies
that the runtime activation event has been seen already. As a
consequence, we cannot receive another event indicating that the runtime
gets activated. This is what the failing assertion checks.
In the case when we have multiple inferiors however, there is a flaw in
what have been described above. If one inferior (let's call it inferior
1) already has the amd-dbgapi-target pushed to its target stack and
another inferior (inferior 2) activates the ROCm runtime, here is what
can happen:
- The driver creates the runtime activation for inferior 2 and writes to
the associated file descriptor.
- GDB has inferior 1 selected and calls target_wait for some reason.
- This prompts amd_dbgapi_target::wait to be called. The method pulls
all events from the driver, including the runtime activation event for
inferior 2, leading to the assertion failure.
The fix for this problem is simple. To avoid such problem, we need to
make sure that amd_dbgapi_target::wait only pulls events for the current
inferior from the driver. This is what this patch implements.
This patch also includes a testcase which could fail before this patch.
This patch has been tested on a system with multiple GPUs which had more
chances to reproduce the original bug. It has also been tested on top
of the downstream ROCgdb port which has more AMDGPU related tests. The
testcase has been tested with `make check check-read1 check-readmore`.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
It is not possible to debug multiple processes simultaneously on all
generations of AMDGPU devices. As some tests will need to debug
multiple inferiors using AMDGPU devices, we need to ensure that all
devices available have the required capability. Failing to do so would
result in GDB not being able to debug all inferiors properly.
Add the hip_devices_support_debug_multi_process helper function used to
ensure that all devices available can debug multiple processes.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Setting PYTHONMALLOC helped me locate an earlier bug. It seems to me
that there aren't big downsides to always setting this during testing,
and it might help find other bugs in the future.
|
|
Two fixes in gdb.python/py-thread-exited.exp:
- fix the copyright notice validity range (PR testsuite/30687):
2022-202 -> 2022-2023, and
- add missing "require allow_python_tests".
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30687
|
|
As reported in PR testsuite/30633, when running test-case
gdb.dwarf2/typeddwarf.exp with target board native-gdbserver on Ubuntu
22.04.2, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x0000000000000001 in ?? ()^M
(gdb) FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main
...
We run into the FAIL as follows:
- due to using gdbserver, we attach at the point of the first instruction, in
_start
- we then set a breakpoint at main
- the test-case is a .s file, that has main renamed to _start in the assembly,
but not in the debuginfo
- setting a breakpoint at main sets the breakpoint at the same instruction
we're currently stopped at
- continue doesn't hit the breakpoint, and we return out of _start, which
causes a sigsegv
Note that this is for the amd64 case (using gdb.dwarf2/typeddwarf-amd64.S).
For the i386 case (using gdb.dwarf2/typeddwarf.S), setting a breakpoint in
main sets it one insn after function entry, and consequently the problem does
not occur.
The FAIL is a regression since commit 90cce6c0551 ("[gdb/testsuite] Add nopie
in a few test-cases").
Without nopie the executable is PIE, with nopie it's static instead.
In the PIE case, we attach at the point of _start in the dynamic linker, and
consequently we do not skip the breakpoint in main, and also don't run into
the FAIL.
Fix this by:
- removing the -nostdlib setting, and
- renaming _start to main in both .S files.
The change to use -nostdlib and rename main to _start was originally added
in commit 6edba76fe8b (submitted here:
https://sourceware.org/pipermail/gdb-patches/2011-May/082657.html ) , I assume
to fix the problem now fixed by using nopie.
Tested on x86_64-linux.
Reported-By: Simon Marchi <simon.marchi@efficios.com>
Tested-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30633
|
|
With CLI, a session defining a command looks like:
...
(gdb) define foo
Type commands for definition of "foo".
End with a line saying just "end".
>bar
>end
(gdb)
...
With TUI however, we get the same secondary prompts, and type the same, but
are left with:
...
(gdb) define foo
Type commands for definition of "foo".
End with a line saying just "end".
(gdb)
...
Fix this by calling tui_inject_newline_into_command_window in
gdb_readline_wrapper_line, as is done in tui_command_line_handler.
Tested on x86_64-linux.
PR tui/30636
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30636
|
|
7.5.0 some more
With a gdb build with -O2 -flto=auto and gcc 7.5.0 and test-case
gdb.gdb/python-helper.exp I run into:
...
(outer-gdb) continue^M
Continuing.^M
print 1^M
^M
Thread 1 "xgdb" hit Breakpoint 2, \
_Z11value_printP5valueP7ui_filePK19value_print_options (val=0x22e2590, \
stream=0x1f65480, options=0x7fffffffcdc0) at gdb/valprint.c:1193^M
1193 {^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
...
This is the "value_print" variant of the problem with "c_print_type" I fixed
in commit 0d332f11122 ("[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2
-flto=auto and gcc 7.5.0").
Fix this likewise.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/step-over-syscall.exp without glibc debuginfo
installed, I get:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00007ffff7d4405e in vfork () from /lib64/libc.so.6^M
(gdb) PASS: gdb.base/step-over-syscall.exp: vfork: displaced=off: \
continue to vfork (1st time)
...
but with glibc debuginfo installed I get instead:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00007ffff7d4405e in __libc_vfork () at \
../sysdeps/unix/sysv/linux/x86_64/vfork.S:44^M
44 ENTRY (__vfork)^M
(gdb) FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: \
continue to vfork (1st time)
...
The FAIL is due to a mismatch with regexp:
...
"Breakpoint \[0-9\]+, (.* in |__libc_|)$syscall \\(\\).*"
...
because it cannot match both ".* in " and the __libc_ prefix.
Fix this by using instead the regexp:
...
"Breakpoint \[0-9\]+, (.* in )?(__libc_)?$syscall \\(\\).*"
...
Tested on x86_64-linux.
|
|
For *reasons* I was hacking on gdb.base/foll-vfork.exp and wanted to
change the name of the binary that was created. Should be easy, I
adjusted the global $binfile variable .... but that didn't work.
In one place the script uses $testfile instead of $binfile.
Fixed this to use $binfile, now I can easily change the name of the
generated binary, and the test still works.
There's no change in what is tested after this commit.
|
|
I noticed in test-case gdb.arch/arm-pthread_cond_timedwait-bt.exp that
prepare_for_testing is used, followed by a clean_restart.
This calls clean_restart twice in a row.
Fix this by using build_executable instead.
Also, I noticed that the test-case requires an SVC instruction, so add a
require to limit the test-case to supported architectures.
While we're at it, run M-x indent-region in emacs to fix indentation.
Tested on x86_64-linux.
|
|
Use "require !readnow" in two test-cases, instead of the written-out variant.
Tested on x86_64-linux, with target boards unix and readnow.
|
|
Jakub pointed out that using DW_FORM_implicit_const with
DW_AT_bit_size would cause gdb to crash. This happened because
DW_FORM_implicit_const is not an "unsigned" form, causing as_unsigned
to assert. This patch fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30651
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This implements the DAP "modules" request, and also arranges to add
the module ID to stack frames.
|
|
This adds a new objfile_for_address method to gdb.Progspace. This
makes it easy to find the objfile for a given address.
There's a related PR; and while this change would have been sufficient
for my original need, it's not clear to me whether I should close the
bug. Nevertheless I think it makes sense to at least mention it here.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19288
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Ada 2022 adds the "target name symbol", which can be used on the right
hand side of an assignment to refer to the left hand side. This
allows for convenient updates. This patch implements this for gdb's
Ada expression parser.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
The DAP disassemble command lets the client return the underlying
bytes of the instruction in an implementation-defined format. This
patch updates gdb to return this, and simply uses a hex string of the
bytes as the format.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Consider the test-case:
...
$ cat main.c
int main (void) { return 0; }
$ cat static-optimized-out.c
static int aaa;
...
compiled like this:
...
$ gcc-12 static-optimized-out.c main.c -g -O2 -flto
...
There's a difference in behaviour depending on symtab expansion state:
...
$ gdb -q -batch a.out -ex "print aaa"
No symbol "aaa" in current context.
$ gdb -q -batch a.out -ex "maint expand-symtab" -ex "print aaa"
$1 = <optimized out>
...
The reason for the difference is that the optimized out variable aaa:
...
<1><104>: Abbrev Number: 2 (DW_TAG_variable)
<105> DW_AT_name : aaa
<109> DW_AT_decl_file : 1
<10a> DW_AT_decl_line : 18
<10b> DW_AT_decl_column : 12
<10c> DW_AT_type : <0x110>
...
is not added to the cooked index because of this clause in abbrev_table::read:
...
else if (!has_location && !has_specification_or_origin && !has_external
&& cur_abbrev->tag == DW_TAG_variable)
cur_abbrev->interesting = false;
...
Fix this inconsistency by making sure that the optimized out variable is added
to the cooked index.
Regression tested on x86_64-linux.
Add two test-cases, a C test-case gdb.opt/static-optimized-out.exp and a dwarf
assembly test-case gdb.dwarf2/static-optimized-out.exp.
Tested gdb.opt/static-optimized-out.exp with gcc-8 to gcc-12, for which we now
consistently get:
...
(gdb) print aaa^M
$1 = <optimized out>^M
...
and with gcc 7.5.0 and clang 13.0.1, for which we still consistently get:
...
(gdb) print aaa^M
No symbol "aaa" in current context.^M
...
due to missing debug info for the variable.
PR symtab/30656
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30656
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In test-case gdb.tui/long-prompt.exp, with a prompt of 40 chars, the same size
as the terminal width, we get a superfluous newline at line 19:
...
16 (gdb) set prompt 123456789A123456789B123
17 456789C123456789>
18 123456789A123456789B123456789C123456789>
19
20 123456789A123456789B123456789C123456789>
21 set prompt (gdb)
22 (gdb)
...
as well as a superfluous repetition of the prompt at line 20 once we type the
's' starting "set prompt".
I traced the superfluous newline back to readline's readline_internal_setup,
that does:
...
/* If we're not echoing, we still want to at least print a prompt, because
rl_redisplay will not do it for us. If the calling application has a
custom redisplay function, though, let that function handle it. */
if (_rl_echoing_p == 0 && rl_redisplay_function == rl_redisplay)
...
else
{
if (rl_prompt && rl_already_prompted)
rl_on_new_line_with_prompt ();
else
rl_on_new_line ();
(*rl_redisplay_function) ();
...
and then we hit the case that calls rl_on_new_line_with_prompt, which does:
...
/* If the prompt length is a multiple of real_screenwidth, we don't know
whether the cursor is at the end of the last line, or already at the
beginning of the next line. Output a newline just to be safe. */
if (l > 0 && (l % real_screenwidth) == 0)
_rl_output_some_chars ("\n", 1);
...
This doesn't look like a readline bug, because the behaviour matches the
comment.
[ And the fact that the output of the newline doesn't happen in the scope of
tui_redisplay_readline means it doesn't get the prompt wrap detection
treatment, causing start_line to be incorrect, which causes the superfluous
repetition of the prompt. ]
I looked at ways to work around this, and managed by switching off
rl_already_prompted, which we set to 1 in tui_rl_startup_hook:
...
/* Readline hook to redisplay ourself the gdb prompt.
In the SingleKey mode, the prompt is not printed so that
the command window is cleaner. It will be displayed if
we temporarily leave the SingleKey mode. */
static int
tui_rl_startup_hook (void)
{
rl_already_prompted = 1;
if (tui_current_key_mode != TUI_COMMAND_MODE
&& !gdb_in_secondary_prompt_p (current_ui))
tui_set_key_mode (TUI_SINGLE_KEY_MODE);
tui_redisplay_readline ();
return 0;
}
...
Then I started looking at why rl_already_prompted is set to 1.
The use case for rl_already_prompted seems to be:
- app (application, the readline user) outputs prompt,
- app sets rl_already_prompted to 1, and
- app calls readline, which calls rl_on_new_line_with_prompt, which figures
out how long the prompt is, and sets a few readline variables accordingly,
which can be used in the following call to rl_redisplay_function.
AFAICT, TUI does not fit this pattern. It does not output an initial prompt,
rather it writes the prompt in every rl_redisplay_function. It doesn't use
the variables set by rl_on_new_line_with_prompt, instead it figures stuff out
by itself.
Fix this by removing the rl_already_prompted setting.
Also remove the call to tui_redisplay_readline, it's not necessary, the
function is called anyway.
Tested on x86_64-linux, no regressions.
|
|
Andrew reported that the previous change to gdb.Inferior.read_memory &
friends introducing scoped_restore_current_inferior_for_memory broke
gdb.dap/stop-at-main.exp. This is also reported as PR dap/30644.
The root of the problem is that all the methods that now use
scoped_restore_current_inferior_for_memory cause GDB to crash with a
failed assert if they are run on an inferior that is not yet started.
E.g.:
(gdb) python i = gdb.selected_inferior ()
(gdb) python i.read_memory (4,4)
gdb/thread.c:626: internal-error: any_thread_of_inferior: Assertion `inf->pid != 0' failed.
This patch fixes the problem by removing
scoped_restore_current_inferior_for_memory's ctor ptid parameter and
the any_thread_of_inferior calls completely, and making
scoped_restore_current_inferior_for_memory switch inferior_ptid to a
pid ptid.
I was a little worried that some port might be assuming inferior_ptid
points at a thread in the xfer_partial memory access routines. We
know that anything that supports forks must not assume that, due to
how detach_breakpoints works. I looked at a number of xfer_partial
implementations, and didn't see anything that is looking at
inferior_ptid in a way that would misbehave. I'm thinking that we
could go forward with this and just fix ports if they break.
While on some ports like on AMD GPU we have thread-specific address
spaces, and so when accessing memory for those address spaces, we must
have the right thread context (via inferior_ptid) selected, in
Inferior.read_memory, we only have the inferior to work with, so this
API as is can't be used to access thread-specific address spaces.
IOW, it can only be used to access the global address space that is
visible to both the CPU and the GPUs.
In proc-service.c:ps_xfer_memory, the other spot using
scoped_restore_current_inferior_for_memory, we're always accessing
per-inferior memory.
If we end up using scoped_restore_current_inferior_for_memory later to
set up the context to read memory from a specific thread, then we can
add an alternative ctor that takes a thread_info pointer, and make
inferior_ptid point to the thread, for example.
New test added to gdb.python/py-inferior.exp, exercising
Inferior.read_memory without execution.
No regressions on native and extended-gdbserver x86_64 GNU/Linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30644
Change-Id: I11309c5ddbbb51a4594cf63c21b3858bfd9aed19
|
|
With a gdb build with -O2 -flto=auto using gcc 7.5.0, I run into:
...
(gdb) ptype global_c^M
^M
Thread 1 "xgdb" hit Breakpoint 3, \
_Z12c_print_typeP4typePKcP7ui_fileii8languagePK18type_print_options () at \
gdb/c-typeprint.c:175^M
175 {^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb again
...
This is a problem with the debug info, which marks the CU containing the
function declaration as C rather than C++. This is fixed in gcc 8 and later.
Work around this compiler problem by allowing the mangled name.
Tested on x86_64-linux.
PR testsuite/30648
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30648
|
|
While working on gdb.base/foll-vfork.exp I noticed that there are
several random 'sleep' calls throughout the test.
The comment suggests these are to allow for output from a vforked
child to arrive, but in each case the test is about to close and
restart GDB, so I don't see how random output from a child process
could impact testing.
I removed the sleep calls and couldn't reproduce any failures from
this test, I left the test running for a couple of hours, and tried
loading my machine, and the test seems fine with these removed.
I've left this as a separate commit so that if, in the future, someone
can show that these are required, it will be easy to revert this one
patch and bring them back.
There should be no change in what is tested after this commit.
|
|
This commit provides tests for all of the bugs fixed in the previous
four commits, this is achieved by expanding gdb.base/foll-vfork.exp to
run with different configurations:
* target-non-stop on/off
* non-stop on/off
* schedule-multiple on/off
We don't test with schedule-multiple on if we are using a remote
target, this is due to bug gdb/30574. I've added a link to that bug
in this commit, but all this commit does is expose that bug, there's
no fixes here.
Some of the bugs fixed in the previous commits are very timing
dependent, as such, they don't always show up. I've had more success
when running this test on a very loaded machine -- I usually run ~8
copies of the test in parallel, then the bugs would normally show up
pretty quickly.
Other than running the test in more configurations, I've not made any
changes to what is actually being tested, other than in one place
where, when testing with non-stop mode, GDB stops in a different
inferior, as such I had to add a new 'inferior 2' call, this can be
found in vfork_relations_in_info_inferiors.
I have cleaned things up a little, for example, making use of
proc_with_prefix to remove some with_test_prefix calls.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30574
|
|
For *reasons* I was looking at gdb.base/foll-vfork.exp. This test
script has a proc 'setup_gdb' that could (potentially) fail. The
setup_gdb proc is called from many places and I, initially, didn't
think that we were checking if setup_gdb had failed or not.
My confusion was because I didn't understand what this tcl construct
did:
return -code return
this will actually act as a return in the context of a proc's caller,
effectively returning two levels of the call stack. Neat (I guess).
So it turns out my worries were misplaced, everywhere setup_gdb is
called, if setup_gdb fails then we will (magically) return.
However, I did spot one place where we managed to confuse ourselves
with our cleverness.
In check_vfork_catchpoints, this proc is called to check that GDB is
able to catch vforks or not. This proc is called early in the test
script, and the intention is that, should this proc fail, we'll mark
the whole test script as unsupported and then move onto the next test
script.
However, check_vfork_catchpoints also uses setup_gdb, and so, if that
call to setup_gdb fails we'll end up returning immediately from
check_vfork_catchpoints, and then continue with the test of _this_
test script, which is not correct.
To fix this I see two choices, one is remove the use of 'return -code
return' from setup_gdb, however, this would require every use of
setup_gdb to then be placed inside:
if { ![setup_gdb] } {
return
}
Or, I can wrap the one call to setup_gdb in check_vfork_catchpoints
and check its return code.
I chose the second option as this is the smaller code change.
There should be no change in what is tested after this commit.
|
|
gdb.testsuite/gdb-caching-proc-consistency.exp
With test-case gdb.testsuite/gdb-caching-proc-consistency.exp we run into:
...
ERROR: no fileid for xerxes
Couldn't send help target native to GDB.
UNRESOLVED: <exp>: have_native_target: initial: help target native
...
Fix this by handling have_native_target in
gdb.testsuite/gdb-caching-proc-consistency.exp.
Tested on x86_64-linux.
|
|
After the commit:
commit 6647f05df023b63bbe056e9167e9e234172fa2ca
Date: Tue Jan 24 18:13:38 2023 +0100
gdb: defer warnings when loading separate debug files
It was pointed out[1] that the warnings being deferred and then later
emitted lacked styling. The warnings lacked styling before the above
commit, but it was suggested that the filenames in these warnings
should be styled, and this commit does this.
There were a couple of previous attempts[2][3][4] to solve this
problem, but these all tried to extend the mechanism introduced in the
above commit, the deferred warnings were placed directly into a
std::vector, but now we tried to, when appropriate, style these
warnings. The review feedback that this approach looked too complex.
So instead, this revision adds a new helper class 'deferred_warnings'
which can be used to collect a set of deferred warnings, and then emit
these deferred warnings later, if needed. This helper class hides the
complexity, so at the point the deferred warning is created no extra
logic is required.
The deferred_warnings class will style the deferred warnings only if
gdb_stderr supports styling. GDB's warnings are sent to gdb_stderr,
so this should ensure we only style when expected.
There was also review feedback[5] that all of the warnings should be
bundled into a single string_file, this has not been done. I feel
pretty strongly that separate warnings should be emitted using
separate "warning" calls. If we do end up with multiple warnings in
this case they aren't really related, one will be about looking up
debug via .gnu_debuglink, while the other will be about build-id based
lookup. So I'd really rather keep the warnings separate.
[1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/
[2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/
[3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/
[4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/
[5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/
Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
When running test-case gdb.dwarf2/forward-spec.exp with check-read1 we run
into:
...
parent: ((cooked_index_entry *) 0xFAIL: <exp>: v has a parent
7fdc1c002ed0) [ns]^M
...
The problem is using regexps containing '.' to avoid escaping, which makes
them too generic.
Fix this by eliminating the '.' from the regexps.
Tested on x86_64-linux.
|
|
A user noticed that Inferior.read_memory and a few other Python APIs
will always use the currently selected inferior, not the one passed to
the call.
This patch fixes the bug by arranging to switch to the inferior. I
found this same issue in several APIs, so this fixes them all.
I also added a few missing calls to INFPY_REQUIRE_VALID to these
methods.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30615
Approved-By: Pedro Alves <pedro@palves.net>
|
|
py-inferior.exp creates a Python variable named 'str'. This clashes
with the built-in type of the same name and can be confusing when
trying to evaluate Python code when debugging the test case. This
patch renames it.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
This changes py-inferior.exp to make it a bit more robust when adding
new inferiors during the course of the test.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
While working on this series, I noticed a some oddities in
py-inferior.exp. One is an obviously incorrect comment, and the
others are confusing test names. This patch fixes these.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
This ensures that 'unset tdesc filename' does not generate any output
on a "bare" native target inferior without an attached process.
|
|
Move logic from auto-connect-native-target.exp into this helper.
|
|
When using "list" with no arguments, GDB will first print the lines
around where the inferior is stopped, then print the next N lines until
reaching the end of file, at which point it warns the user "Line X out
of range, file Y only has X-1 lines.". This is usually desirable, but
if the user can no longer see the original line, they may have forgotten
the current line or that a list command was used at all, making GDB's
error message look cryptic. It was reported in bugzilla as PR cli/30497.
This commit improves the user experience by changing the behavior of
"list" slightly when a user passes no arguments. It now prints that the
end of the file has been reached and recommends that the user use the
command "list ." instead.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently, after the user has used the list command once, there is no
self-contained way to ask GDB to print the location where the inferior is
stopped. The current best options require either using a separate
command to scope out where the inferior is stopped, or using "list *$pc"
requiring knowledge of GDB standard registers. This commit adds a way
to do that using '.' as a new argument for the 'list' command. If the
inferior isn't running, the command prints around the main function.
Because this necessitated having the inferior running and the test was
(seemingly unnecessarily) using printf in a non-essential way and it
would make the resulting log harder to read for no benefit, it was
replaced by a different statement.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This patch removes many TODOs from the gdb.cp tests.
Going through the patch:
* bs15503.exp - these have been commented out forever and rely on
libstdc++ debuginfo. It's better to just remove these.
* classes.exp - the test is wrong, I think, according to the C++ ABI
that gdb understands; and the test can be fixed and comments removed
with a simple change to the code.
* ctti.exp - there's no need to bail out any more, as the test works.
* exception.exp - the code relying on the line numbers can't work,
because gdb never prints that message anyway.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
