Revert "[lldb-dap] Support column breakpoints (#113787)"

This reverts commit 4f48a81a620bc9280be4780f3554cdc9bda55bd3.

The newly added test was failing on the public macOS Arm64 bots:
```
=========

Revert "[lldb-dap] Support column breakpoints (#113787)"

This reverts commit 4f48a81a620bc9280be4780f3554cdc9bda55bd3.

The newly added test was failing on the public macOS Arm64 bots:
```
======================================================================
FAIL: test_column_breakpoints (TestDAP_breakpointLocations.TestDAP_setBreakpoints)
Test retrieving the available breakpoint locations.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/tools/lldb-dap/breakpoint/TestDAP_breakpointLocations.py", line 77, in test_column_breakpoints
self.assertEqual(
AssertionError: Lists differ: [{'co[70 chars]e': 41}, {'column': 3, 'line': 42}, {'column': 18, 'line': 42}] != [{'co[70 chars]e': 42}, {'column': 18, 'line': 42}]

First differing element 2:
{'column': 3, 'line': 41}
{'column': 3, 'line': 42}

First list contains 1 additional elements.
First extra element 4:
{'column': 18, 'line': 42}

[{'column': 39, 'line': 40},
{'column': 51, 'line': 40},
- {'column': 3, 'line': 41},
{'column': 3, 'line': 42},
{'column': 18, 'line': 42}]
Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
----------------------------------------------------------------------
Ran 1 test in 1.554s

FAILED (failures=1)
```

show more ...

[lldb-dap] Support column breakpoints (#113787)

This commit adds support for column breakpoints to lldb-dap.

To do so, support for the `breakpointLocations` request was
added. To find all availa

[lldb-dap] Support column breakpoints (#113787)

This commit adds support for column breakpoints to lldb-dap.

To do so, support for the `breakpointLocations` request was
added. To find all available breakpoint positions, we iterate over
the line table.

The `setBreakpoints` request already forwarded the column correctly to
`SBTarget::BreakpointCreateByLocation`. However, `SourceBreakpointMap`
did not keep track of multiple breakpoints in the same line. To do so,
the `SourceBreakpointMap` is now indexed by line+column instead of by
line only.

See http://jonasdevlieghere.com/post/lldb-column-breakpoints/ for a
high-level introduction to column breakpoints.

show more ...

[lldb-dap] Always pass disableASLR to the DAP executable (#113891)

More context can be found in
https://github.com/llvm/llvm-project/pull/110303

For DAP tests running in constrained environments

[lldb-dap] Always pass disableASLR to the DAP executable (#113891)

More context can be found in
https://github.com/llvm/llvm-project/pull/110303

For DAP tests running in constrained environments (e.g., Docker
containers), disabling ASLR isn't allowed. So we set `disableASLR=False`
(since https://github.com/llvm/llvm-project/pull/113593).

However, the `dap_server.py` will currently only forward the value
of `disableASLR` to the DAP executable if it's set to `True`. If the
DAP executable wasn't provided a `disableASLR` field it defaults to
`true` too:
https://github.com/llvm/llvm-project/blob/f14743794587db102c6d1b20f9c87a1ac20decfd/lldb/tools/lldb-dap/lldb-dap.cpp#L2103-L2104

This means that passing `disableASLR=False` from the tests is currently
not possible.

This is also true for many of the other boolean arguments of
`request_launch`. But this patch only addresses `disableASLR` for now
since it's blocking a libc++ patch.

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

[lldb-dap] Implement `StepGranularity` for "next" and "step-in" (#105464)

VS Code requests the `instruction` stepping granularity if the assembly
view is currently focused. By implementing `StepGra

[lldb-dap] Implement `StepGranularity` for "next" and "step-in" (#105464)

VS Code requests the `instruction` stepping granularity if the assembly
view is currently focused. By implementing `StepGranularity`, we can
hence properly single-step through assembly code.

show more ...

[lldb-dap] Added "port" property to vscode "attach" command. (#91570)

Adding a "port" property to the VsCode "attach" command likely extends
the functionality of the debugger configuration to allow

[lldb-dap] Added "port" property to vscode "attach" command. (#91570)

Adding a "port" property to the VsCode "attach" command likely extends
the functionality of the debugger configuration to allow attaching to a
process using PID or PORT number.
Currently, the "Attach" configuration lets the user specify a pid. We
tell the user to use the attachCommands property to run "gdb-remote ".
Followed the below conditions for "attach" command with "port" and "pid"
We should add a "port" property. If port is specified and pid is not,
use that port to attach. If both port and pid are specified, return an
error saying that the user can't specify both pid and port.

Ex - launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "lldb-dap Debug",
"type": "lldb-dap",
"request": "attach",
"gdb-remote-port":1234,
"program": "${workspaceFolder}/a.out",
"args": [],
"stopOnEntry": false,
"cwd": "${workspaceFolder}",
"env": [],

}
]
}

---------

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 flaky TestDAP_console test. (#94494)

Test Plan:
llvm-lit
llvm-project/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py

Fix dap variable value format issue (#90799)

While adding a UI feature in VSCode to toggle hex/dec in variables view
window. I noticed that it does not work after second toggle. Then I
noticed tha

Fix dap variable value format issue (#90799)

While adding a UI feature in VSCode to toggle hex/dec in variables view
window. I noticed that it does not work after second toggle. Then I
noticed that there is a bug that we only explicitly set hex format not
reset back to default during further toggle. The new test demonstrates
the bug.

This PR resets the format back to default if not using hex. One
complexity is that, we explicitly set registers value format to
AddressInfo, which shouldn't be overridden by default or hex settings.

---------

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

show more ...

Initial step in targets DAP support (#86623)

This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.

The implementation disassembles a

Initial step in targets DAP support (#86623)

This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.

The implementation disassembles all the call instructions in step range
and try to resolve operand name (assuming one operand) using debug info.
Later, the call target function name is chosen by end user and specified
in the StepInto() API call.

It is v1 because of using the existing step in target function name API.
This implementation has several limitations:
* Won't for indirect/virtual function call -- in most cases, our
disassembler won't be able to solve the indirect call target
address/name.
* Won't work for target function without debug info -- if the target
function has symbol but not debug info, the existing
ThreadPlanStepInRange won't stop.
* Relying on function names can be fragile -- if there is some middle
glue/thunk code, our disassembler can only resolve the glue/thunk code's
name not the real target function name. It can be fragile to depend
compiler/linker emits the same names for both.
* Does not support step into raw address call sites -- it is a valid
scenario that in Visual Studio debugger, user can explicitly choose a
raw address to step into which land in the function without debug
info/symbol, then choose UI to load the debug info on-demand for that
module/frame to continue exploring.

A more reliable design could be extending the ThreadPlanStepInRange to
support step in based on call-site instruction offset/PC which I will
propose in next iteration.

---------

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

show more ...

Re-land [lldb-dap] Add support for data breakpoint. (#81909)

This implements functionality to handle DataBreakpointInfo request and
SetDataBreakpoints request.

Previous commit
https://github.co

Re-land [lldb-dap] Add support for data breakpoint. (#81909)

This implements functionality to handle DataBreakpointInfo request and
SetDataBreakpoints request.

Previous commit
https://github.com/llvm/llvm-project/commit/8c56e78ec531f0e2460213c20fff869b6b7add99
was reverted because setting 1 byte watchpoint failed in the new test on
ARM64. So, I changed the test to setting 4 byte watchpoint instead, and
hope this won't break it again. It also adds the fixes from
https://github.com/llvm/llvm-project/pull/81680.

show more ...

Revert "[lldb-dap] Add support for data breakpoint. (#81541)" (#81812)

This reverts commit 8c56e78ec531f0e2460213c20fff869b6b7add99.

Reverting to address the LLDB test failure in ARM64.

[lldb-dap] Add support for data breakpoint. (#81541)

This implements functionality to handle `DataBreakpointInfo` request and
`SetDataBreakpoints` request.

If variablesReference is 0 or not prov

[lldb-dap] Add support for data breakpoint. (#81541)

This implements functionality to handle `DataBreakpointInfo` request and
`SetDataBreakpoints` request.

If variablesReference is 0 or not provided, interpret name as ${number
of bytes}@${expression} to set data breakpoint at the given expression
because the spec
https://microsoft.github.io/debug-adapter-protocol/specification#Requests_DataBreakpointInfo
doesn't say how the client could specify the number of bytes to watch.

This is based on top of https://github.com/llvm/llvm-project/pull/80753.

show more ...

Fix command escape bug in lldb-dap (#72902)

https://github.com/llvm/llvm-project/pull/69238 caused breakage in
VSCode debug console usage -- the user's input is always treated as
commands instead

Fix command escape bug in lldb-dap (#72902)

https://github.com/llvm/llvm-project/pull/69238 caused breakage in
VSCode debug console usage -- the user's input is always treated as
commands instead of expressions (the same behavior as if empty command
escape prefix is specified).

The bug is in one overload of `GetString()` which did not respect the
default value of "\`". But more important, I am puzzled to find out why
the regression is not caught by lldb test (testdap_evaluate). Turns out
https://github.com/llvm/llvm-project/pull/69238 specifies
commandEscapePrefix default value in test framework to be "\`" while
VSCode will default not specify any commandEscapePrefix at all. Changing
it to None will fail `testdap_evaluate`. We should align the default
behavior between DAP client and testcase.

This patches fixes the bug in `GetString()` and changed the default
value of commandEscapePrefix in testcases to be None (be consistent with
IDE).

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

show more ...

[lldb-dap] Add an option to provide a format for threads (#72196)

When this option gets enabled, descriptions of threads will be generated
using the format provided in the launch configuration inst

[lldb-dap] Add an option to provide a format for threads (#72196)

When this option gets enabled, descriptions of threads will be generated
using the format provided in the launch configuration instead of
generating it manually in the dap code. This allows lldb-dap to show an
output similar to the one in the CLI.
This is very similar to https://github.com/llvm/llvm-project/pull/71843

show more ...

[lldb-dap] Add an option to provide a format for stack frames (#71843)

When this option gets enabled, descriptions of stack frames will be
generated using the format provided in the launch configur

[lldb-dap] Add an option to provide a format for stack frames (#71843)

When this option gets enabled, descriptions of stack frames will be
generated using the format provided in the launch configuration instead
of simply calling `SBFrame::GetDisplayFunctionName`. This allows
lldb-dap to show an output similar to the one in the CLI.

show more ...

[lldb-vscode] Allow specifying a custom escape prefix for LLDB commands (#69238)

We've been using the backtick as our escape character, however that
leads to a weird experience on VS Code, because

[lldb-vscode] Allow specifying a custom escape prefix for LLDB commands (#69238)

We've been using the backtick as our escape character, however that
leads to a weird experience on VS Code, because on most hosts, as soon
as you type the backtick on VS Code, the IDE will introduce another
backtick. As changing the default escape character might be out of
question because other plugins might rely on it, we can instead
introduce an option to change this variable upon lldb-vscode
initialization.
FWIW, my users will be using : instead ot the backtick.

show more ...

[lldb] Remove more references to lldb-vscode (#69696)

There are some uses of "vscode" in
`lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py` where
I'm not sure if it's referring to

[lldb] Remove more references to lldb-vscode (#69696)

There are some uses of "vscode" in
`lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py` where
I'm not sure if it's referring to the adapter or VS Code itself, so
those remain.

show more ...

[lldb] Rename lldb-vscode to lldb-dap (#69264)

Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:

[lldb] Rename lldb-vscode to lldb-dap (#69264)

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/

show more ...