🍒 lldb-dap cherrypicks
#9436
Merged
🍒 lldb-dap cherrypicks
#9436
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…#99926) Added "gdb-remote-port" and "gdb-remote-hostname" attach properties usage in README.md and updated package.json version to 0.2.3 This was missed in PR llvm#91570 --------- Co-authored-by: Santhosh Kumar Ellendula <[email protected]> Co-authored-by: Santhosh Kumar Ellendula <[email protected]> (cherry picked from commit 7345025)
lldb-dap already supports a log file which can be enabled by setting the `LLDBDAP_LOG` environment variable. With this commit, the log location can be set directly through the VS-Code extension settings. Also, this commit bumps the version number, such that the new VS Code extension gets published to the Marketplace. (cherry picked from commit 7898866)
…lvm#104824) `SBCommand::AddCommand()` requires `SBCommandPluginInterface` to be heap based because it will be stored inside `std::shared_ptr<lldb::SBCommandPluginInterface>` later for reference counting. But lldb-dap passes `StartDebuggingRequestHandler/ReplModeRequestHandler` static function pointer to it which will cause corruption later during destruction. This PR fixes this issue by making these two handler heap based. Co-authored-by: jeffreytan81 <[email protected]> (cherry picked from commit 98f2eb7)
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 (cherry picked from commit 6f45602)
…parate lines. (llvm#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 llvm#105444 (cherry picked from commit 30ca06c)
This reverts commit 6f45602, which depends on llvm#104523, which I'm reverting. (cherry picked from commit aa70f83)
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 <[email protected]>
(cherry picked from commit e5140ae)
…#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 <[email protected]> Co-authored-by: Santhosh Kumar Ellendula <[email protected]> (cherry picked from commit 89c27d6)
(cherry picked from commit 984fca5)
Bump the lldb-dap version number so that we can publish and updated version in the Visual Studio Marketplace. (cherry picked from commit 7d3b81d)
…ers (llvm#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. (cherry picked from commit 5b4100c)
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. (cherry picked from commit 3acb1ea)
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`. (cherry picked from commit 0cc2cd7)
…ldb-dap process (llvm#108948) Frequently, environment variables such as `LLDB_USE_NATIVE_PDB_READER` are needed to be able to use lldb-dap in vscode This PR adds a way to set the environment for the lldb-dap process using configuration. (cherry picked from commit 30eb193)
* Document how to procure and configure the `lldb-dap` binary
* Improve documentation for `launch.json`:
* Show the examples before the reference. Most new users just want to
get going, and will only need the reference later on
* Deduplicate the list of "launch" and "attach" config settings
* Remove the `stopOnEntry` setting from "attach", since this is a
launch-only setting
* Document the previously undocumented settings `sourcePath`,
`commandEscapePrefix`, `custom{Frame,Thread}Format`, `runInTerminal`
* Add the settings `debuggerRoot` and `sourceMap` to the common section.
So far they were documented as launch-only settings.
* Document that the Debug Console prints variables / expressions by
default and that LLDB commands need to be escaped.
(cherry picked from commit 65c5706)
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. (cherry picked from commit 19ecded)
The `readMemory` request used the `MemoryRegionInfo` so it could also support short reads. Since llvm#106532, this is no longer necessary, as mentioned by @labath in a comment on llvm#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. (cherry picked from commit 786dc5a)
llvm#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. (cherry picked from commit 26e0b50)
…lvm#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. (cherry picked from commit a5876be)
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] (cherry picked from commit e7a43ca)
Apparently, the markdown parser used by the VSCode Marketplace does not support escaped backticks the same way that Github does. This leads to the table of launch / attach options to be rendered as an unformatted blob instead of as a table. See https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.lldb-dap This commit fixes the issue by completely avoiding escaped backticks in the README. While at it, I also fixed a couple of typos / small wording issues. Also, I reordered the ways to procure the `lldb-dap` binary in priority order: Most users should prefer the toolchain-provided binary over building it from source. (cherry picked from commit 9c99e07)
This commit extends the developer docs for `lldb-dap`. It also adds a short "Contributing" section to the user-facing README. Last but not least, it updates the `repository` in the package.json to point to the actual source of truth for the source code, instead of pointing to its mirrored repository. I hope that the VS Code Marketplace properly supports the `directory` property. Unfortunately, I have no way to test this before merging this Pull Request. (cherry picked from commit 6c137b7)
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. (cherry picked from commit 9f8ae78)
… request. (llvm#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. (cherry picked from commit 224f62d)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.