Skip to content

[Debug Info] replace lldb_commands with __lldb_init_module#155336

Open
Walnut356 wants to merge 2 commits intorust-lang:mainfrom
Walnut356:lldb_init_module
Open

[Debug Info] replace lldb_commands with __lldb_init_module#155336
Walnut356 wants to merge 2 commits intorust-lang:mainfrom
Walnut356:lldb_init_module

Conversation

@Walnut356
Copy link
Copy Markdown
Contributor

@Walnut356 Walnut356 commented Apr 15, 2026

View all comments

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

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

@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 15, 2026

Some changes occurred in src/tools/compiletest

cc @jieyouxu

@rustbot rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Apr 15, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 15, 2026

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: @Mark-Simulacrum

@Walnut356
Copy link
Copy Markdown
Contributor Author

now that i think on it, apple's LLDB is a custom fork. I don't think the version extraction logic will work for it. Lemme fix that real quick.

@rust-log-analyzer

This comment has been minimized.

@jieyouxu
Copy link
Copy Markdown
Member

You should be able to run try jobs on this PR urself after this:
@bors delegate=try

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors Bot commented Apr 15, 2026

✌️ @Walnut356, you can now perform try builds on this pull request!

You can now post @bors try to start a try build.

@Walnut356
Copy link
Copy Markdown
Contributor Author

rad, thank you

@rust-log-analyzer

This comment has been minimized.

@jieyouxu jieyouxu self-assigned this Apr 15, 2026
@Walnut356
Copy link
Copy Markdown
Contributor Author

@bors try jobs=aarch64-apple

rust-bors Bot pushed a commit that referenced this pull request Apr 15, 2026
[Debug Info] replace `lldb_commands` with `__lldb_init_module`


try-job: aarch64-apple
@rust-bors

This comment has been minimized.

@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 15, 2026
@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors Bot commented Apr 15, 2026

💔 Test for d52c8f9 failed: CI. Failed job:

@rust-log-analyzer

This comment has been minimized.

@Walnut356
Copy link
Copy Markdown
Contributor Author

Okay, bad news is this test didn't go exactly as planned because debugger.version was only added recently and is not present in apple's LLDB. The good news is:

  1. I can confirm it's not present via apple's repo (llvm's for comparison) so I should be able to check for similar things without running a try job.
  2. apple's LLDB does have the type recognizer enum value so those should work

i'm still iffy on whether I want to just update the tests, or if i want to force a StructSummaryProvider and save us from annoyances like this in the future (at the cost of some minor performance losses).

@Walnut356
Copy link
Copy Markdown
Contributor Author

I guess I should also note that, in additional bad news, apples versioning scheme seems to have 0 relation to llvm's, so using raw version numbers probably won't work. I should be able to just check for features via getattr to check what functions and values are present at runtime

@rust-bors

This comment has been minimized.

jhpratt added a commit to jhpratt/rust that referenced this pull request Apr 25, 2026
…youxu

Account for `GetSyntheticValue` failures

`GetSyntheticValue` returns an invalid `SBValue` if no synthetic is present. That wasn't a problem before when we  were attaching synthetics to every type, but it won't be the case once github.com/rust-lang/pull/155336 or similar lands. Additionally, codelldb subverts `lldb_commands` to apply similar behavior that doesn't attach synthetics to every type, so this fixes a regression there too.

Additionally, I removed 1 useless instance of `GetSyntheticValue`, since pointers should always be `IndirectionSyntheticProvider`, not `DefaultSyntheticProvider`.
@Walnut356
Copy link
Copy Markdown
Contributor Author

i'm still iffy on whether I want to just update the tests, or if i want to force a StructSummaryProvider

I think i'm just gonna update the tests for now since it's a bit safer. I can always go in and enforce StructSummaryProvider later.

@Walnut356
Copy link
Copy Markdown
Contributor Author

Nevermind, I'm really not fond of the formatting inconsistency in nested structs. StructSyntheticProvider it is.

@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 28, 2026

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@rust-log-analyzer

This comment has been minimized.

@Walnut356
Copy link
Copy Markdown
Contributor Author

@bors try jobs=aarch64-apple

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request May 4, 2026
[Debug Info] replace `lldb_commands` with `__lldb_init_module`


try-job: aarch64-apple
@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors Bot commented May 4, 2026

💔 Test for 5b4aa68 failed: CI. Failed job:

@rust-log-analyzer
Copy link
Copy Markdown
Collaborator

The job aarch64-apple failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [debuginfo-lldb] tests/debuginfo/captured-fields-1.rs stdout ----
NOTE: compiletest thinks it is using LLDB version 1703

error: check directive(s) from `/Users/runner/work/rust/rust/tests/debuginfo/captured-fields-1.rs` not found in debugger output. errors:
    (captured-fields-1.rs:36) `(captured_fields_1::main::{closure_env#2}) test = {_ref__my_ref:0x[...]}`
the following subset of check directive(s) was found successfully:
    (captured-fields-1.rs:30) `(captured_fields_1::main::{closure_env#0}) test = {_ref__my_ref__my_field1:0x000000016fdfce60} `
    (captured-fields-1.rs:33) `(captured_fields_1::main::{closure_env#1}) test = {_ref__my_ref__my_field2:0x000000016fdfce64} `
    (captured-fields-1.rs:39) `(captured_fields_1::main::{closure_env#3}) test = {my_ref:{my_field1:11, my_field2:22}} `
    (captured-fields-1.rs:42) `(captured_fields_1::main::{closure_env#4}) test = {my_var__my_field2:22} `
    (captured-fields-1.rs:45) `(captured_fields_1::main::{closure_env#5}) test = {my_var:{my_field1:11, my_field2:22}} `
status: exit status: 0
command: LLDB_BATCHMODE_SCRIPT_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/captured-fields-1.lldb/captured-fields-1.debugger.script" LLDB_BATCHMODE_TARGET_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/captured-fields-1.lldb/a" PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/lib/rustlib/aarch64-apple-darwin/lib:/opt/homebrew/lib/ruby/gems/3.3.0/bin:/opt/homebrew/opt/ruby@3.3/bin:/Users/runner/.local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/runner/.cargo/bin:/usr/local/opt/curl/bin:/usr/local/bin:/usr/local/sbin:/Users/runner/bin:/Users/runner/.yarn/bin:/Users/runner/Library/Android/sdk/tools:/Users/runner/Library/Android/sdk/platform-tools:/Library/Frameworks/Python.framework/Versions/Current/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/Users/runner/.dotnet/tools" PYTHONPATH="/Users/runner/work/rust/rust/src/etc" PYTHONUNBUFFERED="1" "lldb" "--one-line" "script --language python -- import lldb_batchmode; lldb_batchmode.main()"
--- stdout -------------------------------
(lldb) script --language python -- import lldb_batchmode; lldb_batchmode.main()
LLDB batch-mode script
----------------------
Debugger commands script is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/captured-fields-1.lldb/captured-fields-1.debugger.script'.
Target executable is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/captured-fields-1.lldb/a'.
Current working directory is '/Users/runner/work/rust/rust'
Creating a target for '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/captured-fields-1.lldb/a'
settings set auto-confirm true

settings set target.inherit-tcc true

version
lldb-1703.0.236.21 Apple Swift version 6.2.3 (swiftlang-6.2.3.3.21 clang-1700.6.3.2) 
command script import /Users/runner/work/rust/rust/src/etc/lldb_lookup.py
breakpoint set --file 'captured-fields-1.rs' --line 63
DEBUG: breakpoint added, id = 1
Breakpoint 1: where = a`captured_fields_1::main + 52 at captured-fields-1.rs:63:5, address = 0x0000000100000808 
DEBUG: registering breakpoint callback, id = 1
Error while trying to register breakpoint callback, id = 1, message = error: could not get num args: can't find callable: breakpoint_callback

breakpoint set --file 'captured-fields-1.rs' --line 69
DEBUG: breakpoint added, id = 2
Breakpoint 2: where = a`captured_fields_1::main + 68 at captured-fields-1.rs:69:5, address = 0x0000000100000818 
DEBUG: registering breakpoint callback, id = 2
Error while trying to register breakpoint callback, id = 2, message = error: could not get num args: can't find callable: breakpoint_callback

breakpoint set --file 'captured-fields-1.rs' --line 75
DEBUG: breakpoint added, id = 3
Breakpoint 3: where = a`captured_fields_1::main + 80 at captured-fields-1.rs:75:5, address = 0x0000000100000824 
DEBUG: registering breakpoint callback, id = 3
Error while trying to register breakpoint callback, id = 3, message = error: could not get num args: can't find callable: breakpoint_callback

breakpoint set --file 'captured-fields-1.rs' --line 81
DEBUG: breakpoint added, id = 4
Breakpoint 4: where = a`captured_fields_1::main + 92 at captured-fields-1.rs:81:5, address = 0x0000000100000830 
DEBUG: registering breakpoint callback, id = 4
Error while trying to register breakpoint callback, id = 4, message = error: could not get num args: can't find callable: breakpoint_callback

breakpoint set --file 'captured-fields-1.rs' --line 87
DEBUG: breakpoint added, id = 5
Breakpoint 5: where = a`captured_fields_1::main + 104 at captured-fields-1.rs:87:5, address = 0x000000010000083c 
DEBUG: registering breakpoint callback, id = 5
Error while trying to register breakpoint callback, id = 5, message = error: could not get num args: can't find callable: breakpoint_callback

breakpoint set --file 'captured-fields-1.rs' --line 93
DEBUG: breakpoint added, id = 6
Breakpoint 6: where = a`captured_fields_1::main + 124 at captured-fields-1.rs:93:5, address = 0x0000000100000850 
DEBUG: registering breakpoint callback, id = 6
Error while trying to register breakpoint callback, id = 6, message = error: could not get num args: can't find callable: breakpoint_callback

run
Process 17880 launched: '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/captured-fields-1.lldb/a' (arm64) Process 17880 stopped * thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100000808 a`captured_fields_1::main at captured-fields-1.rs:63:5 60 let a = &mut my_ref.my_field1; 61 }; 62 -> 63 _zzz(); // #break ^ 64 65 let test = || { 66 let a = &my_ref.my_field2; Target 0: (a) stopped. 
v test
(captured_fields_1::main::{closure_env#0}) test = {_ref__my_ref__my_field1:0x000000016fdfce60} 
continue
v test
(captured_fields_1::main::{closure_env#1}) test = {_ref__my_ref__my_field2:0x000000016fdfce64} 
continue
v test
(captured_fields_1::main::{closure_env#2}) test = {_ref__my_ref:{*_ref__my_ref:{my_field1:11, my_field2:22}}} 
continue
v test
(captured_fields_1::main::{closure_env#3}) test = {my_ref:{my_field1:11, my_field2:22}} 
continue
v test
(captured_fields_1::main::{closure_env#4}) test = {my_var__my_field2:22} 
continue
v test
(captured_fields_1::main::{closure_env#5}) test = {my_var:{my_field1:11, my_field2:22}} 
continue
quit
------------------------------------------
--- stderr -------------------------------
warning: This version of LLDB has no plugin for the language "rust". Inspection of frame variables will be limited.
------------------------------------------

---- [debuginfo-lldb] tests/debuginfo/captured-fields-1.rs stdout end ----
---- [debuginfo-lldb] tests/debuginfo/numeric-types.rs stdout ----
NOTE: compiletest thinks it is using LLDB version 1703

error: check directive(s) from `/Users/runner/work/rust/rust/tests/debuginfo/numeric-types.rs` not found in debugger output. errors:
    (numeric-types.rs:202) `[...] 11 { 0 = { 0 = 11 } }`
    (numeric-types.rs:205) `[...] 22 { 0 = { 0 = 22 } }`
    (numeric-types.rs:208) `[...] 33 { 0 = { 0 = 33 } }`
    (numeric-types.rs:211) `[...] 44 { 0 = { 0 = 44 } }`
    (numeric-types.rs:214) `[...] 55 { 0 = { 0 = 55 } }`
    (numeric-types.rs:217) `[...] 66 { 0 = { 0 = 66 } }`
    (numeric-types.rs:220) `[...] 77 { 0 = { 0 = 77 } }`
    (numeric-types.rs:223) `[...] 88 { 0 = { 0 = 88 } }`
    (numeric-types.rs:226) `[...] 99 { 0 = { 0 = 99 } }`
    (numeric-types.rs:229) `[...] 100 { 0 = { 0 = 100 } }`
    (numeric-types.rs:232) `[...] 111 { 0 = { 0 = 111 } }`
    (numeric-types.rs:235) `[...] 122 { 0 = { 0 = 122 } }`
status: exit status: 0
command: LLDB_BATCHMODE_SCRIPT_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/numeric-types.debugger.script" LLDB_BATCHMODE_TARGET_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a" PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/lib/rustlib/aarch64-apple-darwin/lib:/opt/homebrew/lib/ruby/gems/3.3.0/bin:/opt/homebrew/opt/ruby@3.3/bin:/Users/runner/.local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/runner/.cargo/bin:/usr/local/opt/curl/bin:/usr/local/bin:/usr/local/sbin:/Users/runner/bin:/Users/runner/.yarn/bin:/Users/runner/Library/Android/sdk/tools:/Users/runner/Library/Android/sdk/platform-tools:/Library/Frameworks/Python.framework/Versions/Current/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/Users/runner/.dotnet/tools" PYTHONPATH="/Users/runner/work/rust/rust/src/etc" PYTHONUNBUFFERED="1" "lldb" "--one-line" "script --language python -- import lldb_batchmode; lldb_batchmode.main()"
--- stdout -------------------------------
(lldb) script --language python -- import lldb_batchmode; lldb_batchmode.main()
LLDB batch-mode script
----------------------
Debugger commands script is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/numeric-types.debugger.script'.
Target executable is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a'.
Current working directory is '/Users/runner/work/rust/rust'
Creating a target for '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a'
settings set auto-confirm true

settings set target.inherit-tcc true

version
lldb-1703.0.236.21 Apple Swift version 6.2.3 (swiftlang-6.2.3.3.21 clang-1700.6.3.2) 
command script import /Users/runner/work/rust/rust/src/etc/lldb_lookup.py
breakpoint set --file 'numeric-types.rs' --line 284
DEBUG: breakpoint added, id = 1
Breakpoint 1: where = a`numeric_types::main + 1324 at numeric-types.rs:284:5, address = 0x0000000100000d50 
DEBUG: registering breakpoint callback, id = 1
Error while trying to register breakpoint callback, id = 1, message = error: could not get num args: can't find callable: breakpoint_callback

run
Process 21256 launched: '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a' (arm64) Process 21256 stopped * thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100000d50 a`numeric_types::main at numeric-types.rs:284:5 281 let a_u64 = AtomicU64::new(512); 282 let a_usize = AtomicUsize::new(1024); 283 -> 284 zzz(); // #break ^ 285 } 286 287 fn zzz() { } Target 0: (a) stopped. 
v/d nz_i8
(core::num::nonzero::NonZero<char>) nz_i8 = 11 { 0 = {0:'\v'} } 
v nz_i16
(core::num::nonzero::NonZero<short>) nz_i16 = 22 { 0 = {0:22} } 
v nz_i32
(core::num::nonzero::NonZero<int>) nz_i32 = 33 { 0 = {0:33} } 
v nz_i64
(core::num::nonzero::NonZero<long>) nz_i64 = 44 { 0 = {0:44} } 
v nz_i128
(core::num::nonzero::NonZero<__int128>) nz_i128 = 55 { 0 = {0:55} } 
v nz_isize
(core::num::nonzero::NonZero<long>) nz_isize = 66 { 0 = {0:66} } 
v/d nz_u8
(core::num::nonzero::NonZero<unsigned char>) nz_u8 = 77 { 0 = {0:'M'} } 
v nz_u16
(core::num::nonzero::NonZero<unsigned short>) nz_u16 = 88 { 0 = {0:88} } 
v nz_u32
(core::num::nonzero::NonZero<unsigned int>) nz_u32 = 99 { 0 = {0:99} } 
v nz_u64
(core::num::nonzero::NonZero<unsigned long>) nz_u64 = 100 { 0 = {0:100} } 
v nz_u128
(core::num::nonzero::NonZero<unsigned __int128>) nz_u128 = 111 { 0 = {0:111} } 
v nz_usize
(core::num::nonzero::NonZero<unsigned long>) nz_usize = 122 { 0 = {0:122} } 
quit
------------------------------------------
--- stderr -------------------------------
warning: This version of LLDB has no plugin for the language "rust". Inspection of frame variables will be limited.
------------------------------------------

---- [debuginfo-lldb] tests/debuginfo/numeric-types.rs stdout end ----

failures:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants