lldb-dap cherrypicks
#112628
Closed
lldb-dap cherrypicks
#112628
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
This allows the clang driver to know which tool is meant to be executed, which allows the clang driver to load the right clang config files, and allows clang to find colocated sysroots. This makes sure that doing `clang-scan-deps -- <tool> ...` looks up things in the same way as if one just would execute `<tool> ...`, when `<tool>` isn't an absolute or relative path. (cherry picked from commit a26ec54)
Since a26ec54, we expand the executable name to an absolute path, if it isn't already one, if found in path. This broke a couple tests in some environments; when the clang workdir resides in a path under e.g. /opt. Tests that only use a tool name like "clang-cl" would get expanded to the absolute path in the build tree. The loop for finding the last "-o" like option for clang-cl command lines would inspect all arguments, including Args[0] which is the executable name itself. As an /opt path matches Arg.starts_with("/o"), this would get detected as an object file output name in cases where there was no other explicit output argument. Thus, this fixes those tests in workdirs under e.g. /opt. (cherry picked from commit cead904)
(cherry picked from commit 63267ca)
In ExpandFPLibCall, an assumption is made that all floating point libcalls that take integer arguments use unsigned integers. In the case of ldexp and frexp, this assumption is incorrect, leading to miscompilation and subsequent target-dependent incorrect operation. Indicate that ldexp and frexp utilize signed arguments in ExpandFPLibCall. Fixes llvm#108904 Signed-off-by: Timothy Pearson <[email protected]> (cherry picked from commit 90c1474)
…rbose_trap support (llvm#110161) We should have been checking against 1700, not 17000, which was a typo. (cherry picked from commit 1eba879)
Large scratch offset with one on highest bit selected as negative, negative offset has same binary representation in 16 bits as large unsigned offset. (cherry picked from commit e9d12a6)
…lvm#110256) Use i32 for offset instead of i16, this way it does not get interpreted as negative 16 bit offset. (cherry picked from commit 83fe851)
Until llvm#103056 lands or another more appropriate check can be found. This test fails on Ubuntu Focal where zdump is built with 32 bit time_t but passes on Ubuntu Jammy where zdump is built with 64 bit time_t. Marking it unsupported means Linaro can upgrade its bots to Ubuntu Jammy without getting an unexpected pass. (cherry picked from commit 6f6422f)
This fixes the test on Arm 32 bit Ubuntu Jammy where time_t is 32 bit. (cherry picked from commit cdd608b)
…lvm#90967) Multiple invocations of the pass could interfere with eachother, preventing some undefs being initialised. I found it very difficult to create a unit test for this due to it being dependent on particular allocations of a previous function. However, the bug can be observed here: https://godbolt.org/z/7xnMo41Gv with the creation of the illegal instruction `vnsrl.wi v9, v8, 0`
…20240723 [lldb][FrameRecognizer] Make VerboseTrapFrameRecognizer aware of Swift-C++ interop frames
…ssing NoCD8 (llvm#109579) Promoted KMOV* was encoded with CD8 incorrectly, see https://godbolt.org/z/cax513hG1 (cherry picked from commit 0d334d8)
This was mistakely changed by llvm#109579, which doesn't match with other EVEX decoding. (cherry picked from commit 70529b2)
rdar://136232178 rdar://136231390
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)
JDevlieghere
requested review from
a team,
Endilll,
aaupov,
ayermolo,
cyndyishida,
daniel-grumberg,
dcci,
maksfb and
rafaelauler
as code owners
Member
Author
|
Wrong merge base. Apologies for the noise. |
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.