| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 changes the DAP breakpointLocations request to accept a Source
and to decode it properly.
|
|
This changes the gdb DAP implementation to emit a real
sourceReference, rather than emitting 0. Sources are tracked in some
maps in sources.py, and a new helper function is introduced to compute
the "Source" object that can be sent to the client.
|
|
The DAP 'module' event may include a 'path' component. I noticed that
this is supplied even when the module in question does not come from a
file.
This patch only emits this field when the objfile corresponds to a
real file.
No test case, because I wasn't sure how to write a portable one.
However, it's clear from gdb.log on Linux:
{"type": "event", "event": "module", "body": {"reason": "new", "module": {"id": "system-supplied DSO at 0x7ffff7fc4000", "name": "system-supplied DSO at 0x7ffff7fc4000"}}, "seq": 21}
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30676
|
|
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
|
|
A subsequent patch will add the ability to suppress breakpoint events
to DAP. My first attempt at this ended up with recurse imports,
causing Python failures. So, this patch moves all the DAP breakpoint
event code to breakpoint.py in preparation for the change.
I've renamed breakpoint_descriptor here as well, because it can now be
private to breakpoint.py.
|
|
Vladimir Makaev noticed that, in some cases, a DAP stackTrace response
would include a relative path name for the "path" component.
This patch changes the frame decorator code to add a new DAP-specific
decorator, and changes the DAP entry point to frame filters to use it.
This decorator prefers the symtab's full name, and does not fall back
to the solib's name.
I'm not entirely happy with this patch, because if a user frame filter
uses FrameDecorator, it may still do the wrong thing. It would be
better to have frame filters return symtab-like objects instead, or to
have a separate method to return the full path to the source file.
I also tend to think that the solib fallback behavior of
FrameDecorator is a mistake. If this is ever needed, it seems to me
that it should be a separate method.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30665
|
|
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.
|
|
In Python, a member name starting with "__" is specially handled to
make it "more private" to the class -- it isn't truly private, but it
is renamed to make it less likely to be reused by mistake. This patch
ensures that this is done for the private method of FrameDecorator.
|
|
Reports a thread exit according to the DAP spec:
https://microsoft.github.io/debug-adapter-protocol/specification#Events_Thread
This patch requires the ThreadExitedEvent to be checked in,
in order to work. That patch is found here https://sourceware.org/pipermail/gdb-patches/2023-June/200071.html
Formatted correctly using black
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30474
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
|
|
Tom de Vries found a bug where, sometimes, a SIGCHLD would be
delivered to a non-main thread, wreaking havoc.
The problem is that gdb.block_signals after first blocking a set of
signals, then unblocked the same set rather than restoring the initial
situation. This function being called from the DAP thread lead to
SIGCHLD being unblocked there.
This patch fixes the problem by restoring the previous set of signals
instead.
Tested-by: Tom de Vries <tdevries@suse.de>
Reviewed-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30680
|
|
Doug Evans, Yao Qi and myself are stepping down as GDB Global
Maintainers. This commit therefore moves our entries to the
"Past Maintainers" section.
I've also removed myself as Ada maintainer, as well as MIPS
authorized committer.
|
|
I noticed that the variable main_thread:
...
/* The main thread. */
static std::thread::id main_thread;
...
has a confusing name and corresponding comment, because it doesn't contain the
main thread, but rather the main thread's std::thread::id.
Fix this by renaming to main_thread_id.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Tom de Vries filed a bug about an intermittent gdb DAP failure -- and
coincidentally, at the same time, Alexandra Hájková sent email about a
somewhat similar failure.
After looking into this for a while (with no results) using ASan and
valgrind, I found that setting PYTHONMALLOC=malloc_debug found the bug
instantly.
The problem is that gdbpy_parse_and_eval releases the GIL while
calling parse_and_eval, but fails to re-acquire it before calling
value_to_value_object. This is easily fixed by introducing a new
scope.
I wonder whether the test suite should unconditionally set
PYTHONMALLOC=malloc_debug.
Tested-by: Tom de Vries <tdevries@suse.de>
Reviewed-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30686
|
|
In a review [1], I pointed out that applying the patch, git would say:
.git/rebase-apply/patch:147: new blank line at EOF.
However, since the empty line is in target-delegates.c (a generated
file), there's nothing the author can do about it. To avoid this
comment coming up again in the future, change make-target-delegates.py
to avoid the trailing empty line. Do this by making it output empty
lines before each entity, not after.
Since this needs removing a newline output in gdbcopyright, adjust
ada-unicode.py and gdbarch.py to avoid changes in the files they
generate.
[1] https://inbox.sourceware.org/gdb-patches/20230427210113.45380-1-jhb@FreeBSD.org/T/#m083598405bef19157f67c9d97846d3dd90dc7d1c
Change-Id: Ic4c648f06443b432168cb76603402c918aa6e5d2
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While looking at the DAP spec, I noticed that the breakpointLocations
request is gated behind a capability. This patch changes gdb to
report this capability.
I've also added a comment to explain the fact that arguments to
breakpointLocations are not optional, even though the spec says they
are.
|
|
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
|
|
When building gdb with -O2 -fsanitize-threads, I ran into
a Werror=stringop-truncation.
The problem is here in coff_getfilename in coffread.c:
...
strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN);
buffer[FILNMLEN] = '\0';
...
The constant FILNMLEN is expected to designate the size of
aux_entry->x_file.x_n.x_fname, but that's no longer the case since commit
60ebc257517 ("Fixes a buffer overflow when compiling assembler for the MinGW
targets.").
Fix this by using "sizeof (aux_entry->x_file.x_n.x_fname)" instead.
Likewise in xcoffread.c.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/30669
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30669
|
|
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.
|
|
In gdb/tui/tui-layout.c, we have:
...
static window_types_map known_window_types;
...
and in gdb/python/py-tui.c:
...
/* A global list of all gdbpy_tui_window_maker objects. */
static intrusive_list<gdbpy_tui_window_maker> m_window_maker_list;
};
/* See comment in class declaration above. */
intrusive_list<gdbpy_tui_window_maker>
gdbpy_tui_window_maker::m_window_maker_list;
...
With a gdb build with -O0 or -O2, the static destructor calling order seems to be:
- first gdb/tui/tui-layout.c,
- then gdb/python/py-tui.c.
So when running test-case gdb.python/tui-window-factory.exp, we see the
following order of events:
- the destructor for known_window_types is called, which triggers calling the
destructor for the only element E of m_window_maker_list. The destructor
destroys E, and also removes E from m_window_maker_list, leaving it empty.
- the destructor for m_window_maker_list is called. It's empty, so it's a nop.
However, when building gdb with -O2 -flto=auto, the static destructor calling
order seems to be reversed.
Instead, we have these events:
- the destructor for m_window_maker_list is called. This doesn't destroy it's
only element E, but it does make m_window_maker_list empty.
- the destructor for known_window_types is called, which triggers calling the
destructor for E. An attempt is done to remove E from m_window_maker_list,
but we run into an assertion failure, because the list is empty.
Fix this by checking is_linked () before attempting to remove from
m_window_maker_list, similar to how things were addressed in commit 995a34b1772
("Guard against frame.c destructors running before frame-info.c's").
Tested on x86_64-linux.
PR tui/30646
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30646
|
|
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.
|
|
The DAP start_thread helper function has a 'name' parameter that is
unused. Apparently I forgot to hook it up to the thread constructor.
This patch fixes the oversight.
|
|
While working on an experiment, I realized that I needed the DAP
block_signals function. I figured other developers may need it as
well, so this patch moves it from DAP to the gdb module and exports
it.
I also added a new subclass of threading.Thread that ensures that
signals are blocked in the new thread.
Finally, this patch slightly rearranges the documentation so that
gdb-side threading issues and functions are all discussed in a single
node.
|
|
This commit adjusts some of the debug output in linux-nat.c, but makes
no other functional changes to GDB.
In resume_lwp I've added the word "sibling" to one of the debug
messages. All the other debug messages in this function talk about
operating on the sibling thread, so I think it makes sense, for
consistency, if the message I've updated also talks about the sibling
thread.
In resume_stopped_resumed_lwps I've reordered the condition checks so
that the vfork-parent check now happens after the checks for whether
the thread is already resumed or not. This makes no functional
difference to GDB, but does, I think, mean we see more helpful debug
messages first.
Consider the situation where a vfork-parent thread is already resumed,
and resume_stopped_resumed_lwps is called. Previously the message
saying that the thread was not being resumed due to being a
vfork-parent, was printed. This might give the impression that the
thread is left in a not resumed state, which is misleading.
After this change we now get a message saying that the thread is not
being resumed due to it not being stopped (i.e. is already resumed).
With this message the already resumed nature of the thread is much
clearer.
I found this change helpful when debugging some vfork related issues.
|
|
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>
|
|
I noticed an unused import in dap/evaluate.py; and also I found out
that my recent changes to use frame filters from DAP left some unused
imports in dap/bt.py.
|
|
I noticed that the documentation for gdb.Value doesn't mention array
indexing.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
In a review, Eli pointed out that @findex is redundant when used with
@defun. This patch removes all such uses from python.texi, plus a
couple uses before @defvar that are also unnecessary.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
I noticed that a doc string py-type.c says "an signed".
This patch corrects it to "a signed".
|
|
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>
|
|
I ran across this very old code in gdb's Ada support. After a bit of
archaeology, we couldn't determine what bug this might have been
working around. It is no longer needed, so this patch removes it.
As this is entirely Ada-specific and was reviewed and tested at
AdaCore, I'm checking it in.
|
|
ROCm programs can load a high number of compute kernels on GPU devices,
especially if lazy code-object loading have been disabled. Each code
object containing such program is loaded once for each device available,
and each instance is reported by GDB as an individual shared library.
We came across situations where the number of shared libraries opened by
GDB gets higher than the allowed number of opened files for the process.
Increasing the opened files limit works around the problem, but there is a
better way this patch proposes to follow.
Under the hood, the GPU code objects are embedded inside the host
application binary and shared library binaries. GDB currently opens the
underlying file once for each shared library it sees. That means that
the same file is re-opened every time a code object is loaded on a GPU.
This patch proposes to only open each underlying file once. This is
done by implementing a reference counting mechanism so the underlying
file is opened when the underlying file first needs to be opened, and
closed when the last BFD using the underlying file is closed.
On a program where GDB used to open about 1500 files to load all shared
libraries, this patch makes it so only 54 opened file descriptors are
needed.
I have tested this patch on downstream ROCgdb's full testsuite and
upstream GDB testsuite with no regression.
Approved-By: Pedro Alves <pedro@palves.net>
|
