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

[LLDB][LLDB-DAP] Wire up DAP to listen to external progress events (#123826)

Recently I added SBProgress (#119052), and during that original commit I
tested if the progress event was sent over LLDB

[LLDB][LLDB-DAP] Wire up DAP to listen to external progress events (#123826)

Recently I added SBProgress (#119052), and during that original commit I
tested if the progress event was sent over LLDB-DAP, and it was. However
upon the suggestion of @JDevlieghere and @labath we added an external
category (#120171), which I did not test.

This small patch wires up DAP to listen for external events by default,
and adds the external category to the SBDebugger enumeration.

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

Rework the `Option` library to reduce dynamic relocations (#119198)

Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change f

Rework the `Option` library to reduce dynamic relocations (#119198)

Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change focuses on the
option's prefixed names and the array of prefixes. These are present in
every option and the dominant source of dynamic relocations for PIE or
PIC users of LLVM and Clang tooling. In some cases, 100s or 1000s of
them for the Clang driver which has a huge number of options.

This PR addresses this by building a string table and a prefixes table
that can be referenced with indices rather than pointers that require
dynamic relocations. This removes almost 7k dynmaic relocations from the
`clang` binary, roughly 8% of the remaining dynmaic relocations outside
of vtables. For busy-boxing use cases where many different option tables
are linked into the same binary, the savings add up a bit more.

The string table is a straightforward mechanism, but the prefixes
required some subtlety. They are encoded in a Pascal-string fashion with
a size followed by a sequence of offsets. This works relatively well for
the small realistic prefixes arrays in use.

Lots of code has to change in order to land this though: both all the
option library code has to be updated to use the string table and
prefixes table, and all the users of the options library have to be
updated to correctly instantiate the objects.

Some follow-up patches in the works to provide an abstraction for this
style of code, and to start using the same technique for some of the
other strings here now that the infrastructure is in place.

show more ...

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

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

Fixes #95137

[lldb-dap] Fix a warning

This patch fixes:

lldb/tools/lldb-dap/lldb-dap.cpp:1405:16: error: comparison of
integers of different signs: 'int64_t' (aka 'long') and 'size_type'
(aka 'unsigned lo

[lldb-dap] Fix a warning

This patch fixes:

lldb/tools/lldb-dap/lldb-dap.cpp:1405:16: error: comparison of
integers of different signs: 'int64_t' (aka 'long') and 'size_type'
(aka 'unsigned long') [-Werror,-Wsign-compare]

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][lldb-dap] Fix compilation error on 32 bit platforms

https://github.com/llvm/llvm-project/pull/109485 tried to std::min
between size_t and uint64_t. size_t on 32 bit is 32 bits.

https://lab.l

[lldb][lldb-dap] Fix compilation error on 32 bit platforms

https://github.com/llvm/llvm-project/pull/109485 tried to std::min
between size_t and uint64_t. size_t on 32 bit is 32 bits.

https://lab.llvm.org/buildbot/#/builders/18/builds/4430/steps/4/logs/stdio

Explicitly select the size_t template to fix this.

This will truncate one of the arguments but that's the count_requested.
If you're debugging from a 32 bit host and you asked it to read
> 32 bit range of memory from a 64 bit target, you weren't going
to have any success anyway.

The final result needs to be size_t to resize the vector with.

show more ...

[lldb-dap] Simplify `readMemory` (#109485)

The `readMemory` request used the `MemoryRegionInfo` so it could also
support short reads. Since #106532, this is no longer necessary, as
mentioned by @l

[lldb-dap] Simplify `readMemory` (#109485)

The `readMemory` request used the `MemoryRegionInfo` so it could also
support short reads. Since #106532, this is no longer necessary, as
mentioned by @labath in a comment on #104317.

With this commit, we no longer set the `unreadableBytes` in the result.
But this is optional, anyway, according to the spec, and afaik the
VS Code UI does not make good use of `unreadableBytes`, anyway.

We prefer `SBTarget::ReadMemory` over `SBProcess::ReadMemory`, because
the `memory read` command also reads memory through the target instead
of the process, and because users would expect the UI view and the
results from memory read to be in-sync.

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] Add feature to remember last non-empty expression. (#107485)

Update lldb-dap so if the user just presses return, which sends an empty
expression, it re-evaluates the most recent non-empt

[lldb-dap] Add feature to remember last non-empty expression. (#107485)

Update lldb-dap so if the user just presses return, which sends an empty
expression, it re-evaluates the most recent non-empty
expression/command. Also udpated test to test this case.

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