[lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (#122783)

This moves the ownership of the threads that forward stdout/stderr to
the DAP object itself to ensure

[lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (#122783)

This moves the ownership of the threads that forward stdout/stderr to
the DAP object itself to ensure that the threads are joined and that the
forwarding is cleaned up when the DAP connection is disconnected.

This is part of a larger refactor to allow lldb-dap to run in a
listening mode and accept multiple connections.

This reverts the previous revert and now that the underlying Windows
issue was fixed by 3ea2b546a8d17014d3ecf05356ecfaadf26ed846.

show more ...

Revert "[lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (#120457)"

This reverts commit 0d9cf2671e06c9124a0b5fc753330c39c8b4a791. Breaks the
lldb-aarch64-windows

Revert "[lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (#120457)"

This reverts commit 0d9cf2671e06c9124a0b5fc753330c39c8b4a791. Breaks the
lldb-aarch64-windows buildbot.

show more ...

[lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (#120457)

This moves the ownership of the threads that forward stdout/stderr to
the DAP object itself to ensure

[lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (#120457)

This moves the ownership of the threads that forward stdout/stderr to
the DAP object itself to ensure that the threads are joined and that the
forwarding is cleaned up when the DAP connection is disconnected.

This is part of a larger refactor to allow lldb-dap to run in a
listening mode and accept multiple connections.

---------

Co-authored-by: Pavel Labath <pavel@labath.sk>

show more ...

[lldb-dap] Refactor lldb-dap.cpp to not use global DAP variable. (#116272)

This removes the global DAP variable and instead allocates a DAP
instance in main. This should allow us to refactor lldb-d

[lldb-dap] Refactor lldb-dap.cpp to not use global DAP variable. (#116272)

This removes the global DAP variable and instead allocates a DAP
instance in main. This should allow us to refactor lldb-dap to enable a
server mode that accepts multiple connections.

show more ...

[lldb-dap] Refactor lldb-dap/DAP.{h,cpp} to use its own instance instead of the global instance. (#115948)

The refactor will unblock us for creating multiple DAP instances.

[lldb-dap] Remove `g_dap` references from lldb-dap/LLDBUtils. (#115933)

This refactor removes g_dap references from lldb-dap/LLDBUtils.{h,cpp}
to allow us to create more than one g_dap instance in

[lldb-dap] Remove `g_dap` references from lldb-dap/LLDBUtils. (#115933)

This refactor removes g_dap references from lldb-dap/LLDBUtils.{h,cpp}
to allow us to create more than one g_dap instance in the future.

show more ...

[lldb-dap] Use heterogenous lookups with std::map (NFC) (#115590)

Heterogenous lookups allow us to call find with StringRef, avoiding a
temporary heap allocation of std::string.

[lldb-dap] Refactoring breakpoints to not use the `g_dap` reference. (#115208)

Refactoring breakpoints to not use the `g_dap` reference.

Instead, when a breakpoint is constructed it will be passe

[lldb-dap] Refactoring breakpoints to not use the `g_dap` reference. (#115208)

Refactoring breakpoints to not use the `g_dap` reference.

Instead, when a breakpoint is constructed it will be passed a DAP
reference that it should use for its lifetime.

This is part of a larger refactor to remove the global `g_dap` variable
to allow us to create multiple DAP instances.

---------

Co-authored-by: Pavel Labath <pavel@labath.sk>

show more ...

[NFC][lldb-dap] Clean-up includes (#113839)

This commit cleans up the includes in the `lldb-dap` subfolder. The main
motivation was that I got annoyed by `clangd` always complaining about
unused i

[NFC][lldb-dap] Clean-up includes (#113839)

This commit cleans up the includes in the `lldb-dap` subfolder. The main
motivation was that I got annoyed by `clangd` always complaining about
unused includes while working on lldb-dap.

show more ...

[lldb-dap] Creating an API for sending dap events from a script in lldb-dap. (#112384)

Custom DAP events can be detected using
https://code.visualstudio.com/api/references/vscode-api#debug.onDidRec

[lldb-dap] Creating an API for sending dap events from a script in lldb-dap. (#112384)

Custom DAP events can be detected using
https://code.visualstudio.com/api/references/vscode-api#debug.onDidReceiveDebugSessionCustomEvent.

This API allows an lldb python script to send events to the DAP
client to allow extensions to handle these custom events.

show more ...

[lldb-dap] Improving the naming consistency of startDebugging reverse request. (#112396)

Adjusting the name from `lldb-dap startDebugging` to `lldb-dap
start-debugging` to improve consistency with

[lldb-dap] Improving the naming consistency of startDebugging reverse request. (#112396)

Adjusting the name from `lldb-dap startDebugging` to `lldb-dap
start-debugging` to improve consistency with other names for commands in
lldb/lldb-dap.

show more ...

[lldb-dap] Correct auto-completion based on ReplMode and escape char (#110784)

This commit improves the auto-completion in the Debug Console provided
by VS-Code.

So far, we were always suggestin

[lldb-dap] Correct auto-completion based on ReplMode and escape char (#110784)

This commit improves the auto-completion in the Debug Console provided
by VS-Code.

So far, we were always suggesting completions for both LLDB commands and
for variables / expressions, even if the heuristic already determined
how the given string will be executed, e.g., because the user explicitly
typed the escape prefix. Furthermore, auto-completion after the escape
character was broken, since the offsets were not adjusted correctly.
With this commit we now correctly take this into account.

Even with this commit, auto-completion does not always work reliably:

* VS Code only requests auto-completion after typing the first
alphabetic character, but not after punctuation characters. This means
that no completions are provided after typing "`"
* LLDB does not provide autocompletions if a string is an exact match.
This means if a user types `l` (which is a valid command), LLDB will not
provide "language" and "log" as potential completions. Even worse, VS
Code caches the completion and does client-side filtering. Hence, even
after typing `la`, no auto-completion for "language" is shown in the UI.

Those issues might be fixed in follow-up commits. Also with those known
issues, the experience is already much better with this commit.

Furthermore, I updated the README since I noticed that it was slightly
inaccurate.

show more ...

[lldb-dap] Rename `enableDisplayExtendedBacktrace` (#109521)

The `enable` prefix is a filler word which adds no additional
information. Rename the setting to `displayExtendedBacktrace`

Given tha

[lldb-dap] Rename `enableDisplayExtendedBacktrace` (#109521)

The `enable` prefix is a filler word which adds no additional
information. Rename the setting to `displayExtendedBacktrace`

Given that this setting was only introduced a month ago, and that there
has not been any release since then, I assume that usage is still rather
low. As such, it should be fine to not provide backwards-compatibility
workarounds.

show more ...

[lldb-dap] Provide `declarationLocation` for variables (#102928)

This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug ad

[lldb-dap] Provide `declarationLocation` for variables (#102928)

This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.

For the `declarationLocationReference` we need a variable ID similar to
the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.

While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.

I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published the
declaration locations as value locations, and VS Code Insiders navigated
to the expected places. Looking forward to proper VS Code support for
`declarationLocationReference`.

show more ...

[lldb] Nits on uses of llvm::raw_string_ostream (NFC) (#108745)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610

[lldb] Nits on uses of llvm::raw_string_ostream (NFC) (#108745)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884ba395ad084d for further reference )

* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Avoid unneeded calls to raw_string_ostream::str(), to avoid excess
indirection.

show more ...

[lldb-dap] Enabling instruction breakpoint support to lldb-dap. (#105278)

Added support for "supportsInstructionBreakpoints" capability and now it
this command is triggered when we set instruction

[lldb-dap] Enabling instruction breakpoint support to lldb-dap. (#105278)

Added support for "supportsInstructionBreakpoints" capability and now it
this command is triggered when we set instruction breakpoint.
We need this support as part of enabling disassembly view debugging.
Following features should work as part of this feature enablement:

1. Settings breakpoints in disassembly view: Unsetting the breakpoint is
not happening from the disassembly view. Currently we need to unset
breakpoint manually from the breakpoint List. Multiple breakpoints are
getting set for the same $

2. Step over, step into, continue in the disassembly view

The format for DisassembleRequest and DisassembleResponse at
https://raw.githubusercontent.com/microsoft/vscode/master/src/vs/workbench/contrib/debug/common/debugProtocol.d.ts
.

Ref Images:
Set instruction breakpoint in disassembly view:


After issuing continue:


---------

Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.com>
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-lv.qualcomm.com>

show more ...

Fix dap stacktrace perf issue (#104874)

We have got several customer reporting of slow stepping over the past
year in VSCode.
Profiling shows the slow stepping is caused by `stackTrace` request
w

Fix dap stacktrace perf issue (#104874)

We have got several customer reporting of slow stepping over the past
year in VSCode.
Profiling shows the slow stepping is caused by `stackTrace` request
which can take around 1 second for certain targets. Since VSCode sends
`stackTrace` during each stop event, the slow `stackTrace` request would
slow down stepping in VSCode. Below is the hot path:

```
|--68.75%--lldb_dap::DAP::HandleObject(llvm::json::Object const&)
| |
| |--57.70%--(anonymous namespace)::request_stackTrace(llvm::json::Object const&)
| | |
| | |--54.43%--lldb::SBThread::GetCurrentExceptionBacktrace()
| | | lldb_private::Thread::GetCurrentExceptionBacktrace()
| | | lldb_private::Thread::GetCurrentException()
| | | lldb_private::ItaniumABILanguageRuntime::GetExceptionObjectForThread(std::shared_ptr<lldb_private::Thread>)
| | | |
| | | |--53.43%--lldb_private::FunctionCaller::ExecuteFunction(lldb_private::ExecutionContext&, unsigned long*, lldb_private::EvaluateExpressionOptions const&, lldb_private::DiagnosticManager&, lldb_private::Value&)
| | | | |
| | | | |--25.23%--lldb_private::FunctionCaller::InsertFunction(lldb_private::ExecutionContext&, unsigned long&, lldb_private::DiagnosticManager&)
| | | | | |
| | | | | |--24.56%--lldb_private::FunctionCaller::WriteFunctionWrapper(lldb_private::ExecutionContext&, lldb_private::DiagnosticManager&)
| | | | | | |
| | | | | | |--19.73%--lldb_private::ExpressionParser::PrepareForExecution(unsigned long&, unsigned long&, std::shared_ptr<lldb_private::IRExecutionUnit>&, lldb_private::ExecutionContext&, bool&, lldb_private::ExecutionPolicy)
| | | | | | | lldb_private::ClangExpressionParser::DoPrepareForExecution(unsigned long&, unsigned long&, std::shared_ptr<lldb_private::IRExecutionUnit>&, lldb_private::ExecutionContext&, bool&, lldb_private::ExecutionPolicy)
| | | | | | | lldb_private::IRExecutionUnit::GetRunnableInfo(lldb_private::Status&, unsigned long&, unsigned long&)
| | | | | | | |
```

The hot path is added by https://reviews.llvm.org/D156465 which should
at least be disabled for Linux. Note: I am seeing similar performance
hot path on Mac.

This PR hides the feature behind `enableDisplayExtendedBacktrace` option
which needs to be enabled on-demand.

---------

Co-authored-by: jeffreytan81 <jeffreytan@fb.com>

show more ...

[lldb-dap] When sending a DAP Output Event break each message into separate lines. (#105456)

Previously, when output like `"hello\nworld\n"` was produced by lldb (or
the process) the message would

[lldb-dap] When sending a DAP Output Event break each message into separate lines. (#105456)

Previously, when output like `"hello\nworld\n"` was produced by lldb (or
the process) the message would be sent as a single Output event. By
being a single event this causes VS Code to treat this as a single
message in the console when handling displaying and filtering in the
Debug Console.

Instead, with these changes we send each line as its own event. This
results in VS Code representing each line of output from lldb-dap as an
individual output message.

Resolves #105444

show more ...

[lldb-dap] Support throw and catch exception breakpoints for dynamica… (#97871)

…lly registered languages

First of all, this is done to support exceptions for the Mojo language,
but it's done in

[lldb-dap] Support throw and catch exception breakpoints for dynamica… (#97871)

…lly registered languages

First of all, this is done to support exceptions for the Mojo language,
but it's done in a way that will benefit any other plugin language.

1. I added a new lldb-dap CLI argument (not DAP field) called
`pre-init-commands`. These commands are executed before DAP
initialization. The other `init-commands` are executed after DAP
initialization. It's worth mentioning that the debug adapter returns to
VSCode the list of supported exception breakpoints during DAP
initialization, which means that I need to register the Mojo plugin
before that initialization step, hence the need for `pre-init-commands`.
In general, language plugins should be registered in that step, as they
affect the capabilities of the debugger.
2. I added a set of APIs for lldb-dap to query information of each
language related to exception breakpoints. E.g. whether a language
supports throw or catch breakpoints, how the throw keyword is called in
each particular language, etc.
3. I'm realizing that the Swift support for exception breakpoints in
lldb-dap should have been implemented in this way, instead of hardcoding
it.

show more ...

Reapply PR/87550 (again) (#95571)

New fixes:
- properly init the `std::optional<std::vector>` to an empty vector as
opposed to `{}` (which was effectively `std::nullopt`).

---------

Co-auth

Reapply PR/87550 (again) (#95571)

New fixes:
- properly init the `std::optional<std::vector>` to an empty vector as
opposed to `{}` (which was effectively `std::nullopt`).

---------

Co-authored-by: Vy Nguyen <oontvoo@users.noreply.github.com>

show more ...

Revert "Reapply PR/87550 (#94625)"

This reverts commit 35fa2ded2ac52151be22c206fc92b983d1fd8e30.

It broke the LLDB bots on green dragon

Reapply PR/87550 (#94625)

Re-apply https://github.com/llvm/llvm-project/pull/87550 with fixes.

Details:
Some tests in fuchsia failed because of the newly added assertion.
This was because `GetE

Reapply PR/87550 (#94625)

Re-apply https://github.com/llvm/llvm-project/pull/87550 with fixes.

Details:
Some tests in fuchsia failed because of the newly added assertion.
This was because `GetExceptionBreakpoint()` could be called before
`g_dap.debugger` was initted.

The fix here is to just lazily populate the list in
GetExceptionBreakpoint() rather than assuming it's already been initted.
(There is some nuisance here because we can't simply just populate it in
DAP::DAP(), which is a global ctor and is called before
`SBDebugger::Initialize()` is called. )

show more ...

Revert "[lldb][lldb-dap] Cleanup breakpoint filters." (#93739)

Reverts llvm/llvm-project#87550 because it broke `TestDAP*` lldb tests.

https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchai

Revert "[lldb][lldb-dap] Cleanup breakpoint filters." (#93739)

Reverts llvm/llvm-project#87550 because it broke `TestDAP*` lldb tests.

https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64-rbe/b8746585790559468897/overview

show more ...

[lldb][lldb-dap] Cleanup breakpoint filters. (#87550)

Details:
- remove Swift breakpoint filter because this version of LLDB does not
support Swift.
- only return objc filters when working on m

[lldb][lldb-dap] Cleanup breakpoint filters. (#87550)

Details:
- remove Swift breakpoint filter because this version of LLDB does not
support Swift.
- only return objc filters when working on macos.

show more ...

[lldb-dap] Add timestamps to protocol logs (#93540)

I've found them very useful as a rudimentary form of benchmark.