Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:
s/VSCODE/DAP/
s/VSCode/DAP/
s/vscode/dap/
s/g_vsc/g_dap/
Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/
This can be used to have VS Code debug various emulators, remote
systems, hardware probes, etc.
In my case I was doing this for the Gameboy Advance,
https://github.com/stuij/gba-llvm-devkit/blob/main/docs/Debugging.md#debugging-using-visual-studio-code.
It's not very complex if you know LLDB well, but when using another
plugin, CodeLLDB, I was very glad that they had an example for it. So we
should have one too.
lldb-vscode had installation instructions based on creating a folder
inside ~/.vscode/extensions, which no longer works. A different
installation mechanism is needed based on a VSCode command. More can be
read in the contents of this patch.
Closes https://github.com/llvm/llvm-project/issues/63655
Auto summaries were only being used when non-pointer/reference variables
didn't have values nor summaries. Greg pointed out that it should be
better to simply use auto summaries when the variable doesn't have a
summary of its own, regardless of other conditions.
This led to code simplification and correct visualization of auto
summaries for pointer/reference types, as seen in this screenshot.
<img width="310" alt="Screenshot 2023-09-19 at 7 04 55 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/d356d579-13f2-487b-ae3a-f3443dce778f">
"descriptive summaries" should only be used for small to medium binaries
because of the performance penalty the cause when completing types. I'm
defaulting it to false.
Besides that, the "raw child" for synthetics should be optional as well.
I'm defaulting it to false.
Both options can be set via a launch or attach config, following the
pattern of most settings. javascript extension wrappers can set these
settings on their own as well.
We've been displaying types and addresses for containers, but that's not
very useful information. A better approach is to compose the summary of
containers with the summary of a few of its children.
Not only that, we can dereference simple pointers and references to get
the summary of the pointer variable, which is also better than just
showing an anddress.
And in the rare case where the user wants to inspect the raw address,
they can always use the debug console for that.
For the record, this is very similar to what the CodeLLDB extension
does, and it seems to give a better experience.
An example of the new output:
<img width="494" alt="Screenshot 2023-09-06 at 2 24 27 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/588659b8-421a-4865-8d67-ce4b6182c4f9">
And this is the
<img width="476" alt="Screenshot 2023-09-06 at 2 46 30 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/5768a52e-a773-449d-9aab-1b2fb2a98035">
old output:
This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OPT_##ID`), kind (`Option::KIND##Class`), group ID (`OPT_##GROUP`) and alias ID (`OPT_##ALIAS`). This patch extracts that common code into canonical macros. This results in fewer changes when tweaking the `OPTION` macros emitted by the TableGen backend.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157028
It isn't useful for users to see "<unknown>" as a stack trace when lldb fails to symbolicate a stack frame. I've replaced "<unknown>" with the value of the program counter instead.
Test Plan:
To test this, I opened a target that lldb fails to symbolicate in
VSCode, and observed in the CALL STACK section that instead of being
shown as "<unknown>", those stack frames are represented by their
program counters.
I added a new test case, `TestVSCode_stackTraceMissingFunctionName` that
exercises this feature.
I also ran `lldb-dotest -p TestVSCode` and saw that the tests passed.
Differential Revision: https://reviews.llvm.org/D156732
Summary:
In cases where the PC has no function name, lldb-vscode crashes.
`lldb::SBFrame::GetDisplayFunctionName()` returns a `nullptr`, and when we
attempt to construct an `std::string`, it raises an exception.
Test plan:
This can be observed with creating a test file (credit to @clayborg for
the example):
```
int main() {
typedef void (*FooCallback)();
FooCallback foo_callback = (FooCallback)0;
foo_callback(); // Crash at zero!
return 0;
}
```
and attempting to debug the file through VSCode.
I add a test case in D156732 which should cover this.
Differential Revision: https://reviews.llvm.org/D156970
This makes anlysing test failures much more easy.
For SendJSON this is simple, just use llvm::format instead.
For GetNextObject/ReadJSON it's a bit more tricky.
* Print the "Content-Length:" line in ReadJSON, but not the json.
* Back in GetNextObject, if the JSON doesn't parse, it'll be
printed as a normal string along with an error message.
* If we didn't error before, we have a JSON value so we pretty print it.
* Finally, if it isn't an object we'll log an error for that,
not including the JSON.
Before:
```
<--
Content-Length: 81
{"command":"disconnect","request_seq":5,"seq":0,"success":true,"type":"response"}
```
After:
```
<--
Content-Length: 81
{
"command": "disconnect",
"request_seq": 5,
"seq": 0,
"success": true,
"type": "response"
}
```
There appear to be some responses that include strings that are themselves JSON,
and this won't pretty print those but I think it's still worth doing.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D156979
On Apple platforms when debugging with libBacktraceRecording.dylib backtraces are stored as part of the thread stack. This change includes support for displaying the back traces when they are present in the stack trace.
To use this on macOS a binary needs to be run with the following environment variables configured:
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libBacktraceRecording.dylib
{F28473587}
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D156465
This patch fixes a 32bit integer overflow in lldb-vscode.
The current implementation of frame_id does `(thread_index << 19 | frame_index)`. Since thread_index is a 32 bit integer this leaves only 32 - 19 == 13 bits available for the thread_index. As a result, lldb-vscode can only handle 2^13 == 8192 threads. Normally, this would be sufficient, but we have seen crazy process having +12000 threads, causing the frame_id algorithm above to integer overflow during casting.
The patch fixes the overflow by up casting to 64 bit integer first before bit shifiting.
Differential Revision: https://reviews.llvm.org/D156375
When the process is contiuned using an lldb command expression the thread state in VS Code is never informed and will be out of sync with the current state of the process. The new event will fire whenever the process is continued and keeps the debugger in sync with the dap client.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D154989
This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.
When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:
* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.
Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide auto-completes.
This commit includes updates to the tests to verify the new behavior after the previous failures from submitting https://reviews.llvm.org/D154030.
Differential Revision: https://reviews.llvm.org/D155248
In preparation for removing the #include "llvm/ADT/StringExtras.h"
from the header to source file of llvm/Support/Error.h, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893fa1, 39d8e6e22cd1,
a11efd49266f, and 5551657b310b.
Differential Revision: https://reviews.llvm.org/D155018
This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.
When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:
* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.
Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide auto-completes.
RFC Discussion: https://discourse.llvm.org/t/rfc-lldb-vscode-evaluate-repl-behavior-and-improvements/71667
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D154030
Adds support for a reverse DAP request to startDebugging. The new request can be used to launch child processes from lldb scripts, for example it would be start forward to configure a debug configuration for a server and a client allowing you to launch both processes with a single debug configuraiton.
Reviewed By: wallace, ivanhernandez13
Differential Revision: https://reviews.llvm.org/D153447
This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for both
`int64_t` & `uint64_t` with a public type aliases, respectively
`SignedInteger` & `UnsignedInteger`.
It adds new getter for signed and unsigned interger values to the
`StructuredData::Object` base class and changes the implementation of
`StructuredData::Array::GetItemAtIndexAsInteger` and
`StructuredData::Dictionary::GetValueForKeyAsInteger` to support signed
and unsigned integers.
This patch also adds 2 new `Get{Signed,Unsigned}IntegerValue` to the
`SBStructuredData` class and marks `GetIntegerValue` as deprecated.
Finally, this patch audits all the caller of `StructuredData::Integer`
or `StructuredData::GetIntegerValue` to use the proper type as well the
various tests that uses `SBStructuredData.GetIntegerValue`.
rdar://105575764
Differential Revision: https://reviews.llvm.org/D150485
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
According to the spec, RestartRequest has an optional "arguments" field, which
is a RestartArguments object. RestartArguments has its own optional "arguments"
field, which is a (LaunchRequestArguments | AttachRequestArguments) object. So
we need to to the "arguments" lookup twice to get to the actual launch
arguments.
Differential Revision: https://reviews.llvm.org/D150392
This is an optional request, but supporting it makes the experience
better when re-launching a big binary that takes significant time to
parse: instead of tearing down and re-create the whole session we just
need to kill the current process and launch a new one.
Some non-obvious comments that might help review this change:
* After killing the process, we get an "exited" event for it. Because
the process no longer exists some interesting things can occur that
manifest as flaky failures if not dealt with:
- `EventIsProcessEvent` relies on `SBEvent::GetBroadcasterClass`,
which can crash if the broadcaster is no longer there: the event
only holds a weak_ptr to its broadcaster, and `GetBroadcasterClass`
uses it without checking.
Other `EventIs*` functions look at the flavor of the EventData, so I
have modified EventIsProcessEvent to do that.
- We keep the PID of the old process so we can detect its "exited"
event and not terminate the whole session. But sometimes the
SBProcess we get from the event won't have a PID, for some reason.
* I have factored out the code to launch a process out to a new
LaunchProcess function, so it can be used from both `request_launch`
and `request_restart`.
* The restart_runInTerminal test has the same problem with debug builds
as the original runInTerminal test: when attaching to the launcher
instance of lldb-vscode it takes a long time to parse its debug info.
I have used the same workaround to disable that particular test for
debug builds.
Differential Revision: https://reviews.llvm.org/D147831
With ptrace_scope = 1 the kernel only allows tracing descendants of a
process. When using runInTerminal, the target process is not launched
by the debugger, so we need to modify LaunchRunInTerminal to explicitly
allow tracing. This should fix a problem reported in
https://reviews.llvm.org/D84974#3903716
In order to allow only the main lldb-vscode process to attach to the
target, this change introduces a new `--debugger-pid` flag that needs
to be passed with `--launch-target` and `--comm-file`.
Also, remove a special case from the launch method in the
lldbvscode_testcase test harness. The existing test was using
stopOnEntry, so the first stop didn't happen at the expected breakpoint
unless the harness did configurationDone first.
Differential Revision: https://reviews.llvm.org/D147805
Change lldb-vscode to use the `expression` command for generating completions, instead
of the `p` alias.
Aliases are user overrideable, and even deletable, but the `expression` command is
unchangeable.
See D141539 where a similar replacement was done to tests.
Differential Revision: https://reviews.llvm.org/D145437
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175.
This reverts commit 06b90e2e9c991e211fecc97948e533320a825470.
This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
