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][test] Set disableASLR to False for tests (#113593)

When running in constrained environments like docker, disabling ASLR
might fail with errors like:
```
AssertionError: False is not tr

[lldb-dap][test] Set disableASLR to False for tests (#113593)

When running in constrained environments like docker, disabling ASLR
might fail with errors like:
```
AssertionError: False is not true : launch failed (Cannot launch
'/__w/.../lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.test_subtleFrames/a.out':
personality set failed: Operation not permitted)
```
E.g., https://github.com/llvm/llvm-project/pull/110303

Hence we already run `settings set target.disable-aslr false` as part of
the init-commands for the non-DAP tests (see
https://github.com/llvm/llvm-project/pull/88312 and
https://discourse.llvm.org/t/running-lldb-in-a-container/76801).

But we never adjusted it for the DAP tests. As a result we get
conflicting test logs like:
```
{
"arguments": {
"commandEscapePrefix": null,
"disableASLR": true,
....
"initCommands": [
...
"settings set target.disable-aslr false",
```

Disabling ASLR by default in tests isn't useulf (it's only really a
debugging aid for users). So this patch sets `disableASLR=False` by
default.

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

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

Increase timeout to reduce test failure rate. (#83312)

The timeout for this test was set to 1.0s which is very low, it should
be a default of 10s and be increased by a factor of 10 if ASAN is
enab

Increase timeout to reduce test failure rate. (#83312)

The timeout for this test was set to 1.0s which is very low, it should
be a default of 10s and be increased by a factor of 10 if ASAN is
enabled. This will help reduce the falkiness of the test, especially in
ASAN builds.

show more ...

[lldb-dap] Do not write over the existing error if launchCommands fail during debugger launch. (#82051)

This fixes an issue where the error is lost if a command while executing
`launchCommands` whe

[lldb-dap] Do not write over the existing error if launchCommands fail during debugger launch. (#82051)

This fixes an issue where the error is lost if a command while executing
`launchCommands` when launching the debugger.

This should fix #82048

show more ...

[lldb] Replace assertRegexpMatches with assertRegex (NFC) (#82074)

assertRegexpMatches is a deprecated alias for assertRegex and has been
removed in Python 3.12. This wasn't an issue previously bec

[lldb] Replace assertRegexpMatches with assertRegex (NFC) (#82074)

assertRegexpMatches is a deprecated alias for assertRegex and has been
removed in Python 3.12. This wasn't an issue previously because we used
a vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.

show more ...

[lldb-dap] Implement command directives (#74808)

This adds support for optionally prefixing any command with `?` and/or
`!`.
- `?` prevents the output of a commands to be printed to the console
u

[lldb-dap] Implement command directives (#74808)

This adds support for optionally prefixing any command with `?` and/or
`!`.
- `?` prevents the output of a commands to be printed to the console
unless it fails.
- `!` aborts the dap if the command fails.

They come in handy when programmatically running commands on behalf of
the user without wanting them to know unless they fail, or when a
critical setup is required as part of launchCommands and it's better to
abort on failures than to silently skip.

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][test] Add the ability to extract the variable value out of the summary. (#72631)

Fix for https://github.com/llvm/llvm-project/issues/71897
When it comes to test infrastructure the test (Test

[lldb][test] Add the ability to extract the variable value out of the summary. (#72631)

Fix for https://github.com/llvm/llvm-project/issues/71897
When it comes to test infrastructure the test (TestDAP_variables.py:
test_scopes_variables_setVariable_evaluate_with_descriptive_summaries)
will fail if the variable has a summary along with value.

I just tried to add a summary to a variable before we set a value to the
variable using below expression from “request_setVariable” function.
RunLLDBCommands(llvm::StringRef(), {std::string("type summary add
--summary-string "{sample summary}" (const char **) argv")});

As value has nonnumeric characters where we are trying to convert into
integer, python is throwing an error. We did not see this issue in
upstream as we are not adding summary explicitly, by default we are
getting empty summary & value for all children’s of argv parameter (even
after auto summary).

The test is failing with below error:
ERROR:
test_scopes_variables_setVariable_evaluate_with_descriptive_summaries
(TestDAP_variables.TestDAP_variables)
Traceback (most recent call last):
File
"/llvm/llvm-project/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py",
line 372, in
test_scopes_variables_setVariable_evaluate_with_descriptive_summaries
enableAutoVariableSummaries=True
File
"/llvm/llvm-project/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py",
line 266, in do_test_scopes_variables_setVariable_evaluate
argv = self.get_local_as_int("argv")
File
"//llvm/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py",
line 199, in get_local_as_int
return int(value, 16)
ValueError: invalid literal for int() with base 16: '0x0000000000001234
sample summary'
Config=x86_64-//llvm/llvm-build/bin/clang

Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.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] 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 ...