Skip to content

Commit 4804ad7

Browse files
committed
Auto merge of #155336 - Walnut356:lldb_init_module, r=jieyouxu
[Debug Info] replace `lldb_commands` with `__lldb_init_module` ~~DO NOT MERGE~~. Please run through `aarch64-apple`. Ideally the tests fail. If they don't, the test runner is using too old of a version of LLDB and I need to fiddle with this some more. TL;DR I hate `lldb_commands`, it's annoying to update and maintain since it's just a raw text file of CLI commands. All of the functionality can be replicated via the debugger's own API. `__lldb_init_module` is called immediately upon `command script import lldb_lookup.py`, so it should function identically (with one exception, see below). We can do things like let python tell us the names of the functions and classes, making them easier to keep in sync. Most importantly, we can conditionally use one set of visualizers or another depending on the version of the debugger. This is a precursor to using callback-based type matching, which was added in LLDB 19. The one exception i mentioned above replaces our `".*"` regex that dumps everything through `lldb_lookup.synthetic_lookup`. That wildcard also includes primitives which is less than ideal, especially for performance. It's bad enough that [codelldb intercepts this command and replaces it with a type recognizer](https://github.com/vadimcn/codelldb/blob/39d9accd8c666e3d3d1372abccad12b3d256ed0b/lang_support/rust.py#L50). If i remove `lldb_commands`, codelldb can no longer do this. To prevent a regression on their end, I added [a conditional that replicates that behavior](https://github.com/Walnut356/rust/blob/e4db5e7ccba109dea635b9140cb9f54b6378abf3/src/etc/lldb_lookup.py#L145). Here's the problem: for some godforsaken reason, if a struct contains a field with a `SyntheticProvider` (even one that is "empty", like for `DefaultSyntheticProvider` for primitives) **it is formatted differently than a struct whose fields don't have providers**. That breaks a bunch of the tests because instead of `{ x = 10 y = 30 }` we get `(x = 10, y = 30)`. Very cool. So, we have divergent behavior depending on the version of LLDB. That's nothing new, since MSVC enums are broken prior to LLDB 18, so it's whatever (and the difference hardly matters to the end user). If the CI test runners have a new enough version of LLDB that it uses the type recognizer instead of the wildcard, the tests will fail. I'll update them and we'll be good to go. If they *don't* fail, I need to probably force a struct summary provider so that all versions look the same (which isn't ideal performance), or I can just wait until xcode happens to update to a newer version of LLDB. --- try-job: aarch64-apple
2 parents 4530eac + 7f84e5c commit 4804ad7

40 files changed

Lines changed: 522 additions & 270 deletions

src/bootstrap/src/core/build_steps/dist.rs

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -760,7 +760,6 @@ impl Step for DebuggerScripts {
760760

761761
cp_debugger_script("lldb_lookup.py");
762762
cp_debugger_script("lldb_providers.py");
763-
cp_debugger_script("lldb_commands")
764763
}
765764
}
766765

src/etc/lldb_commands

Lines changed: 0 additions & 86 deletions
This file was deleted.

0 commit comments

Comments
 (0)