Revert "[lldb] Implement basic support for reverse-continue" (#123906)

Reverts llvm/llvm-project#112079 due to failures on the arm bot.

[lldb] Implement basic support for reverse-continue (#112079)

This commit adds support for a
`SBProcess::ContinueInDirection()` API. A user-accessible command for
this will follow in a later commit.

[lldb] Implement basic support for reverse-continue (#112079)

This commit adds support for a
`SBProcess::ContinueInDirection()` API. A user-accessible command for
this will follow in a later commit.

This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. For testing
purposes, this commit adds a Python implementation of *very limited*
record-and-reverse-execute functionality, implemented as a proxy between
lldb and lldb-server in `lldbreverse.py`. This should not (and in
practice cannot) be used for anything except testing.

The tests here are quite minimal but we test that simple breakpoints and
watchpoints work as expected during reverse execution, and that
conditional breakpoints and watchpoints work when the condition calls a
function that must be executed in the forward direction.

show more ...

[lldb-dap] Refactoring JSONUtils to not use `g_dap` and instead passing in required arguments. (#115561)

This is part of a larger refactor to remove the global `g_dap` variable.

[lldb-dap] Fix lldb-dap build for windows, missing PATH_MAX. (#115551)

This should fix https://lab.llvm.org/buildbot/#/builders/141/builds/3722

[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 ...

[lldb] Fix lldb windows build breakage from https://github.com/llvm/llvm-project/pull/113839.

[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] Implement value locations for function pointers (#104589)

This commit adds `valueLocationReference` to function pointers and
function references. Thereby, users can navigate directly to

[lldb-dap] Implement value locations for function pointers (#104589)

This commit adds `valueLocationReference` to function pointers and
function references. Thereby, users can navigate directly to the
pointed-to function from within the "variables" pane.

In general, it would be useful to also a add similar location references
also to member function pointers, `std::source_location`,
`std::function`, and many more. Doing so would require extending the
formatters to provide such a source code location.

There were two RFCs about this a while ago:

https://discourse.llvm.org/t/rfc-extending-formatters-with-a-source-code-reference/68375
https://discourse.llvm.org/t/rfc-sbvalue-metadata-provider/68377/26

However, both RFCs ended without a conclusion. As such, this commit now
implements the lowest-hanging fruit, i.e. function pointers. If people
find it useful, I will revive the RFC afterwards.

show more ...

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

Reverting this again; I added a commit which added @skipIfDarwin
markers to the TestReverseContinueBreakpoints.py and
TestRevers

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

Reverting this again; I added a commit which added @skipIfDarwin
markers to the TestReverseContinueBreakpoints.py and
TestReverseContinueNotSupported.py API tests, which use lldb-server
in gdbserver mode which does not work on Darwin. But the aarch64 ubuntu
bot reported a failure on TestReverseContinueBreakpoints.py,
https://lab.llvm.org/buildbot/#/builders/59/builds/6397

File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 63, in test_reverse_continue_skip_breakpoint
self.reverse_continue_skip_breakpoint_internal(async_mode=False)
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 81, in reverse_continue_skip_breakpoint_internal
self.expect(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2372, in expect
self.runCmd(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1002, in runCmd
self.assertTrue(self.res.Succeeded(), msg + output)
AssertionError: False is not true : Process should be stopped due to history boundary
Error output:
error: Process must be launched.

This reverts commit 4f297566b3150097de26c6a23a987d2bd5fc19c5.

show more ...

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later com

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.

This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.

The majority of this PR is test infrastructure (about 700 of the 950
lines added).

show more ...

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

This reverts commit d5e1de6da96c1ab3b8cae68447e8ed3696a7006e.

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later com

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.

This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.

The majority of this PR is test infrastructure (about 700 of the 950
lines added).

show more ...

Make env and source map dictionaries #95137 (#106919)

Fixes #95137

[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-dap] Support inspecting memory (#104317)

Add support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variables and `evaluate`
responses, s

[lldb-dap] Support inspecting memory (#104317)

Add support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variables and `evaluate`
responses, such that the binary view can be opened from the variables
view and from the "watch" pane.

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] Improve `stackTrace` and `exceptionInfo` DAP request handlers (#105905)

Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.

[lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP request handlers (#105905)

Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.

Additionally adding additional information to the `exceptionInfo`
request to report exception stacks there instead of merging the
exception stack into the stack trace. The `exceptionInfo` request is
only called if a stop event occurs with `reason='exception'`, which
should mitigate the performance of `SBThread::GetCurrentException`
calls.

Adding unit tests for exception handling and stack trace supporting.

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 ...

Revert "Revert "[lldb-dap] Mark hidden frames as "subtle" (#105457)""

This reverts commit aa70f83e660453c006193aab7ba67c94db236948.

Revert "[lldb-dap] Mark hidden frames as "subtle" (#105457)"

This reverts commit 6f456024c37424d9c8cc1cea07126a28f246588d, which
depends on https://github.com/llvm/llvm-project/pull/104523, which I'

Revert "[lldb-dap] Mark hidden frames as "subtle" (#105457)"

This reverts commit 6f456024c37424d9c8cc1cea07126a28f246588d, which
depends on https://github.com/llvm/llvm-project/pull/104523, which I'm
reverting.

show more ...

[lldb-dap] Mark hidden frames as "subtle" (#105457)

This commit takes advantage of the recently introduced
`SBFrame::IsHidden` to show those hidden frames as "subtle" frames in
the UI. E.g., VS Co

[lldb-dap] Mark hidden frames as "subtle" (#105457)

This commit takes advantage of the recently introduced
`SBFrame::IsHidden` to show those hidden frames as "subtle" frames in
the UI. E.g., VS Code hides those stack frames by default, and renders
them as grayed out frames, in case the user decides to show them in the
stack trace

show more ...

New ThreadPlanSingleThreadTimeout to resolve potential deadlock in single thread stepping (#90930)

This PR introduces a new `ThreadPlanSingleThreadTimeout` that will be
used to address potential de

New ThreadPlanSingleThreadTimeout to resolve potential deadlock in single thread stepping (#90930)

This PR introduces a new `ThreadPlanSingleThreadTimeout` that will be
used to address potential deadlock during single-thread stepping.

While debugging a target with a non-trivial number of threads (around
5000 threads in one example target), we noticed that a simple step over
can take as long as 10 seconds. Enabling single-thread stepping mode
significantly reduces the stepping time to around 3 seconds. However,
this can introduce deadlock if we try to step over a method that depends
on other threads to release a lock.

To address this issue, we introduce a new
`ThreadPlanSingleThreadTimeout` that can be controlled by the
`target.process.thread.single-thread-plan-timeout` setting during
single-thread stepping mode. The concept involves counting the elapsed
time since the last internal stop to detect overall stepping progress.
Once a timeout occurs, we assume the target is not making progress due
to a potential deadlock, as mentioned above. We then send a new async
interrupt, resume all threads, and `ThreadPlanSingleThreadTimeout`
completes its task.

To support this design, the major changes made in this PR are:
1. `ThreadPlanSingleThreadTimeout` is popped during every internal stop
and reset (re-pushed) to the top of the stack (as a leaf node) during
resume. This is achieved by always returning `true` from
`ThreadPlanSingleThreadTimeout::DoPlanExplainsStop()` and
`ThreadPlanSingleThreadTimeout::MischiefManaged()`.
2. A new thread-specific async interrupt stop is introduced, which can
be detected/consumed by `ThreadPlanSingleThreadTimeout`.
3. The clearing of branch breakpoints in the range thread plan has been
moved from `DoPlanExplainsStop()` to `ShouldStop()`, as it is not
guaranteed that it will be called.

The detailed design is discussed in the RFC below:

[https://discourse.llvm.org/t/improve-single-thread-stepping/74599](https://discourse.llvm.org/t/improve-single-thread-stepping/74599)

---------

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

show more ...

[lldb-vscode] Use auto summaries whenever variables don't have a summary (#66551)

Auto summaries were only being used when non-pointer/reference variables
didn't have values nor summaries. Greg poi

[lldb-vscode] Use auto summaries whenever variables don't have a summary (#66551)

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">

show more ...

[lldb-vscode][NFC] Access a pointee type in a simpler way

The new code is a bit simpler bit achieves the same goal. A small test was added just in case.

[lldb-vscode] Make descriptive summaries and raw child for synthetics configurable (#65687)

"descriptive summaries" should only be used for small to medium binaries
because of the performance penal

[lldb-vscode] Make descriptive summaries and raw child for synthetics configurable (#65687)

"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.

show more ...