| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes the DAP code to explicitly request that gdb exit.
Previously this could cause crashes, but with the previous cleanups,
this should no longer happen.
This also adds a tests that ensures that gdb exits with status 0.
|
|
For a patch I submitted, the Linaro CI reported a failure:
...
FAIL: gdb.dap/attach.exp: exceptions in log file
...
I ran the test-case locally, and observed the same FAIL in the gdb.sum file.
I then wanted to confirm that I reproduced the exact same problem, but
realized that I couldn't because there's no way for me to know what exception
occurred, and where, because that information is logged in the dap.log.$n
file, and the Linaro CI only saves the gdb.sum and gdb.log files.
This issue is even worse if only the CI can reproduce a FAIL.
Fix this in dap_check_log_file by dumping dap.log.$n to gdb.log when
exceptions are found.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In dap_gdb_start we do:
...
append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap"
...
While the dap log file setting comes before the dap interpreter setting,
the order is the other way around:
- first, the dap interpreter is started
- second, the -iex commands are executed and the log file is initialized.
Consequently, there's a race between dap interpreter startup and dap log file
initialization.
This cannot be fixed by using -eiex instead. Before the interpreter is
started, the "set debug dap-log-file" command is not yet registered.
Fix this by postponing the start of the DAP server until GDB has processed all
command files.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR dap/31386
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386
|
|
In _dap_read_json we have a gdb_expect with clauses that generate errors:
...
timeout {
error "timeout reading json header"
}
eof {
error "eof reading json header"
}
...
Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar
semantics related to errors:
...
# remote_expect works basically the same as standard expect, but it
# also takes care of getting the file descriptor from the specified
# host and also calling the timeout/eof/default section if there is an
# error on the expect call.
.....
When a timeout triggers, it generates a timeout error, which is reported by
gdb_expect, after which it runs the timeout/eof/default clauses, which
generates an eof error, which is reported by runtest.
I think the intention here is to generate just a one error, a timeout error.
Fix this by postponing generating the error until after gdb_expect.
Tested on x86_64-linux, by:
- running all the DAP test-cases and observing no regressions, and
- modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and
observing only a timeout error.
PR testsuite/31382
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31382
|
|
While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP
patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap
log file.
This is normally set up by dap_gdb_start, but the test-case doesn't use it.
Fix this by doing "set debug dap-log-file $logfile" in the test-case.
To make it easy to do so, I've factored out a new proc new_dap_log_file, and
while at likewise a new proc current_dap_log_file.
Note that the log file is currently empty.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Co-workers at AdaCore pointed out that gdb incorrectly implements the
DAP launch and configurationDone requests. It's somewhat strange to
me, but the spec does in fact say that configuration requests should
occur before the executable is known to gdb. This was clarified in
this bug report against the spec:
https://github.com/microsoft/debug-adapter-protocol/issues/452
Fixing 'launch' to start the inferior was straightforward, but this
then required some changes to how breakpoints are handled. In
particular, now gdb will emit the "pending" reason on a breakpoint,
and will suppress breakpoint events during breakpoint setting.
|
|
This changes the test suite to export dap_initialize.
|
|
A user pointed out that gdb will print a Python exception when it gets
an EOF in DAP mode. And, it turns out that an EOF like this also
causes gdb not to exit. This is due to the refactoring that moved the
JSON reader to its own thread -- previously this caused an exception
to propagate and cause an exit, but now it just leaves the reader
hung.
This patch fixes these problems by arranging to handle EOF more
gracefully.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
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>
|
|
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>
|
|
This renames a couple of DAP procs in the testsuite, to clarify that
they are now exported. The cancellation test will need these.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
Yesterday I pushed a patch to fix a small oversight in the DAP code
that caused an instructionReference to be an array instead of a
string.
This patch adds a test case for that regression. This required
exposing the TON form of the response -- something I mentioned might
be necessary when this code was changed to return just the Tcl form.
I tested this by backing out yesterday's bug fix and verifying that a
failure is seen.
|
|
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 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.
|
|
A bug report about the supportsVariablePaging capability in DAP
resulted in a clarification: when this capability is not present, DAP
implementations should ignore the paging parameters to the "variables"
request. This patch implements this clarification.
|
|
Co-workers who work on a program that uses DAP asked for the ability
to have gdb stop at the main subprogram when launching. This patch
implements this extension.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This adds a new "target" to the DAP attach request. This is passed to
"target remote". I thought "attach" made the most sense for this,
because in some sense gdb is attaching to a running process. It's
worth noting that all DAP "attach" parameters are defined by the
implementation.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
A DAP client can report the supportsVariableType capability in the
initialize request. In this case, gdb can include the type of a
variable or expression in various results.
|
|
This implements the DAP "attach" request.
Note that the copyright dates on the new test source file are not
incorrect -- this was copied verbatim from another directory.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This patch augments the DAP launch request with some optional new
parameters that let the client control the command-line arguments and
the environment of the inferior.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
The copyright years in the ROCm files (e.g. solib-rocm.c) are wrong,
they end in 2022 instead of 2023. I suppose because I posted (or at
least prepared) the patches in 2022 but merged them in 2023, and forgot
to update the year. I found a bunch of other files that are in the same
situation. Fix them all up.
Change-Id: Ia55f5b563606c2ba6a89046f22bc0bf1c0ff2e10
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
In the following patch, I change gdb.dap/basic-dap.exp such that after
waiting for some event, it checks if it received another event
meanwhile. To help with this, make dap_wait_for_event_and_check and
_dap_dap_wait_for_event return a list with everything received before
the event of interest. This is similar to what
dap_check_request_and_response returns.
Change-Id: I85c8980203a2dec833937e7552c2196bc137935d
|
|
I think that name describes a bit better what the proc does, it is
similar to "wait_for" in tuiterm.exp.
Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419
|
|
The DAP helper functions generally return TON objects. However, callers
almost all immediately use ton::2dict to convert them to dicts, to
access their contents. This commits makes things a bit simpler for them
by having function return dicts directly instead.
The downside is that the TON objects contain type information. For
instance, a "2" in a TCL dict could have been the integer 2 or the
string "2" in JSON. By converting to TCL dicts, we lose that
information. If some tests specifically want to check the types of some
fields, I think we can add intermediary functions that return TON
objects, without having to complicate other callers who don't care.
Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f
|
|
This catch didn't cause me any trouble, but for the same reason as the
preceding patch, I think it's a bit better to just let any exception
propagate, to make for easier debugging.
Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c
|
|
Following some of my changes, dap_request_and_response was failing and I
didn't know why. I think it's better to make it not catch any
exception, and just make it do a simple "send request, read response".
If an exception is thrown while sending a request or reading a response,
things are going really badly, it's not like we'll want to recover from
that and continue the test.
Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356
|
|
This helps following what happens when reading gdb.log. The downside is
that it becomes harder to tell what text is from GDB and what text is
going to GDB, but I think that seeing responses without seeing requests
is even more confusing. At least, the lines are prefix with >>>, so
when you see this, you know that until the end of the line, it's
something that was sent to GDB, and not GDB output.
Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874
|
|
Prefix some procs that are only used internally with an underscore, to
make it clear they are internal. If they need to be used by some test
later, we can always un-prefix them.
Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d
|
|
The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
to communicate with debuggers. You can find more information here:
https://microsoft.github.io/debug-adapter-protocol/
Frequently this is implemented as a shim, but it seemed to me that GDB
could implement it directly, via the Python API. This patch is the
initial implementation.
DAP is implemented as a new "interp". This is slightly weird, because
it doesn't act like an ordinary interpreter -- for example it doesn't
implement a command syntax, and doesn't use GDB's ordinary event loop.
However, this seemed like the best approach overall.
To run GDB in this mode, use:
gdb -i=dap
The DAP code will accept JSON-RPC messages on stdin and print
responses to stdout. GDB redirects the inferior's stdout to a new
pipe so that output can be encapsulated by the protocol.
The Python code uses multiple threads to do its work. Separate
threads are used for reading JSON from the client and for writing JSON
to the client. All GDB work is done in the main thread. (The first
implementation used asyncio, but this had some limitations, and so I
rewrote it to use threads instead.)
This is not a complete implementation of the protocol, but it does
implement enough to demonstrate that the overall approach works.
There is a rudimentary test suite. It uses a JSON parser written in
pure Tcl. This parser is under the same license as Tcl itself, so I
felt it was acceptable to simply import it into the tree.
There is also a bit of documentation -- just documenting the new
interpreter name.
|
