Cherry-pick SBFrame::GetDescriptionWithFormat #7985
Merged
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
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test windows |
When the process is contiuned using an lldb command expression the thread state in VS Code is never informed and will be out of sync with the current state of the process. The new event will fire whenever the process is continued and keeps the debugger in sync with the dap client. Reviewed By: wallace Differential Revision: https://reviews.llvm.org/D154989 (cherry picked from commit 3ab73a3)
On Apple platforms when debugging with libBacktraceRecording.dylib backtraces are stored as part of the thread stack. This change includes support for displaying the back traces when they are present in the stack trace.
To use this on macOS a binary needs to be run with the following environment variables configured:
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libBacktraceRecording.dylib
{F28473587}
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D156465
(cherry picked from commit 1bf6f55)
Instead of creating psuedo source files for each stack frame this change adopts the new DAP “disassemble” request, allowing clients to inspect assembly instructions of files with debug info in addition to files without debug info. [[ https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Disassemble | spec ]] See attached screenshot of the disassembly view. {F28473848} Reviewed By: wallace Differential Revision: https://reviews.llvm.org/D156493 (cherry picked from commit ca71dc1)
Summary: In cases where the PC has no function name, lldb-vscode crashes. `lldb::SBFrame::GetDisplayFunctionName()` returns a `nullptr`, and when we attempt to construct an `std::string`, it raises an exception. Test plan: This can be observed with creating a test file (credit to @clayborg for the example): ``` int main() { typedef void (*FooCallback)(); FooCallback foo_callback = (FooCallback)0; foo_callback(); // Crash at zero! return 0; } ``` and attempting to debug the file through VSCode. I add a test case in D156732 which should cover this. Differential Revision: https://reviews.llvm.org/D156970 (cherry picked from commit 9a3f0cd)
It isn't useful for users to see "<unknown>" as a stack trace when lldb fails to symbolicate a stack frame. I've replaced "<unknown>" with the value of the program counter instead. Test Plan: To test this, I opened a target that lldb fails to symbolicate in VSCode, and observed in the CALL STACK section that instead of being shown as "<unknown>", those stack frames are represented by their program counters. I added a new test case, `TestVSCode_stackTraceMissingFunctionName` that exercises this feature. I also ran `lldb-dotest -p TestVSCode` and saw that the tests passed. Differential Revision: https://reviews.llvm.org/D156732 (cherry picked from commit 786bab4)
…ointers (llvm#65514) We've been displaying types and addresses for containers, but that's not very useful information. A better approach is to compose the summary of containers with the summary of a few of its children. Not only that, we can dereference simple pointers and references to get the summary of the pointer variable, which is also better than just showing an anddress. And in the rare case where the user wants to inspect the raw address, they can always use the debug console for that. For the record, this is very similar to what the CodeLLDB extension does, and it seems to give a better experience. An example of the new output: <img width="494" alt="Screenshot 2023-09-06 at 2 24 27 PM" src="https://github.com/llvm/llvm-project/assets/1613874/588659b8-421a-4865-8d67-ce4b6182c4f9"> And this is the <img width="476" alt="Screenshot 2023-09-06 at 2 46 30 PM" src="https://github.com/llvm/llvm-project/assets/1613874/5768a52e-a773-449d-9aab-1b2fb2a98035"> old output: (cherry picked from commit 89a81ec)
We were invoking GetChildAtIndex(0) without checking the number of children. This was not crashing but was showing some warnings in python formatters. (cherry picked from commit 01c0a6a)
…llvm#65552) Currently, if the user wants to inspect the raw version of a synthetic variable, they have to go to the debug console and type `frame var <variable>`, which is not a great experience. Taking inspiration from CodeLLDB, this adds a `[raw]` child to every synthetic variable so that this kind of inspection can be done visually. Some examples: <img width="500" alt="Screenshot 2023-09-06 at 7 56 25 PM" src="https://github.com/llvm/llvm-project/assets/1613874/7fefb7c5-0da7-49c7-968b-78ac88348fea"> <img width="479" alt="Screenshot 2023-09-06 at 6 58 25 PM" src="https://github.com/llvm/llvm-project/assets/1613874/6e650567-16e1-462f-9bf5-4a3a605cf6fc"> (cherry picked from commit cf5d8de)
https://lab.llvm.org/buildbot/#/builders/68/builds/59499 caught a failed test introduced by llvm@cf5d8de. The fix is simple. We just need to update some values. (cherry picked from commit 0762b2e)
… configurable (llvm#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. (cherry picked from commit a2a9918)
The new code is a bit simpler bit achieves the same goal. A small test was added just in case. (cherry picked from commit 4a030f5)
…ary (llvm#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"> (cherry picked from commit 96b1784)
This patch fixes a 32bit integer overflow in lldb-vscode. The current implementation of frame_id does `(thread_index << 19 | frame_index)`. Since thread_index is a 32 bit integer this leaves only 32 - 19 == 13 bits available for the thread_index. As a result, lldb-vscode can only handle 2^13 == 8192 threads. Normally, this would be sufficient, but we have seen crazy process having +12000 threads, causing the frame_id algorithm above to integer overflow during casting. The patch fixes the overflow by up casting to 64 bit integer first before bit shifiting. Differential Revision: https://reviews.llvm.org/D156375 (cherry picked from commit ca84935)
The test was expecting vector<basic_string<char>> & while the test returned vector<string> &. Since verify_completions doesn't support regex matching, sidestep the issue by using a custom type (baz). Differential revision: https://reviews.llvm.org/D158893 (cherry picked from commit a7ca117)
(cherry picked from commit 37086ca)
The test was disabled because it was supposedly flakey. I'm not able to reproduce any flakiness. I ran the test in a look with different levels of parallelization and load. Re-enabling the test and monitoring the Darwin bots. (cherry picked from commit 6bdf485)
lldb-vscode had installation instructions based on creating a folder inside ~/.vscode/extensions, which no longer works. A different installation mechanism is needed based on a VSCode command. More can be read in the contents of this patch. Closes llvm#63655 (cherry picked from commit 098c927)
…ote gdbserver (llvm#68866) This can be used to have VS Code debug various emulators, remote systems, hardware probes, etc. In my case I was doing this for the Gameboy Advance, https://github.com/stuij/gba-llvm-devkit/blob/main/docs/Debugging.md#debugging-using-visual-studio-code. It's not very complex if you know LLDB well, but when using another plugin, CodeLLDB, I was very glad that they had an example for it. So we should have one too. (cherry picked from commit 4606712)
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/ (cherry picked from commit 01263c6)
…ds (llvm#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. (cherry picked from commit 1066481)
…1843) 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. (cherry picked from commit d9ec4b2)
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 llvm#71843 (cherry picked from commit 1654d7d)
adrian-prantl
force-pushed
the
119690134
branch
from
fb4d3b6 to
23918a9
Compare
|
@swift-ci test windows |
|
@swift-ci test windows |
6 similar comments
|
@swift-ci test windows |
|
@swift-ci test windows |
|
@swift-ci test windows |
|
@swift-ci test windows |
|
@swift-ci test windows |
|
@swift-ci test windows |
…mat is not specified. (llvm#74861) Currently there's an include in which `[opt]` might be emitted twice if the frame format also asks for it. As a trivial fix, we should manually emit `[opt]` only if a custom frame format is not specified. (cherry picked from commit 07ed325)
This is an extension to the protocol that emits the declaration information along with the metadata of each variable. This can be used by vscode extensions to implement, for example, a "goToDefinition" action in the debug tab, or for showing the value of a variable right next to where it's declared during a debug session. As this is cheap, I'm not gating this information under any setting. (cherry picked from commit 0ea19bd)
adrian-prantl
force-pushed
the
119690134
branch
from
23918a9 to
e1f0309
Compare
|
@swift-ci test |
|
@swift-ci test windows |
Discourse discussion: https://discourse.llvm.org/t/rfc-update-lldb-code-ownership/72253 Differential revision: https://reviews.llvm.org/D156949 (cherry picked from commit 013a8fc)
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. (cherry picked from commit 2a32afd)
(cherry picked from commit a91a664)
|
@swift-ci test |
|
@swift-ci test windows |
|
@swift-ci test clean windows |
|
@swift-ci test windows |
|
@swift-ci clean test windows platform |
|
@swift-ci test windows |
|
test with swiftlang/swift#71023 |
|
test with swiftlang/swift#71023 |
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.
with a whole lot of dependent commit as bycatch.
rdar://119690134