Repository navigation
53 LLDB tests from tests/debuginfo fail on windows-msvc #161657
Description
Activity
And here are the causes behind the failures (more or less)
UDT fields reordered (UDT defined in file, can work around with
repr(c), but also resolves itself withlldb-repr). Additional digging shows that this is technically an LLDB problem. Their DWARF parser preserves the source/debuginfo ordering of fields, their PDB parser reorders them to offset-order:associated-types.rsboxed-struct.rsdestructured-for-loop-variable.rsevec-in-struct.rspacked-struct.rspacked-struct-with-destructor.rssimple-struct.rs<--- this test lies (Structs aren'trepr(c), so e.g.InternalPaddingdoesn't necessarily have internal padding, might end up identical toPaddingAtEnd)struct-with-destructor.rsstruct-in-struct.rs
Tuples (summary provider needs
lldb.eTypeOptionHideChildren):associated-types.rsbox.rsborrowed-tuple.rsc-style-enum-in-composite.rsdestructured-fn-argument.rscross-crate-spans.rsdestructured-for-loop-variable.rsdestructured-local.rssimple-tuple.rstuple-in-tuple.rsstrings-and-strs.rs
Globals (need to investigate whether this is an LLDB or PDB issue):
basic-types-globals.rs#no-ltobasic-types-globals.rs#ltono_mangle-info.rs
i8/u8formats to char instead of decimal:borrowed-unique-basic.rsdestructured-for-loop-variable.rs
Type names included in output, different type name on different targets (fixes itself with
lldb-repr):captured-fields-1.rsgeneric-struct.rsmethod-on-generic-struct.rsstrings-and-strs.rs
<no location, value may have been optimized out>(possibly LLDB issue, possibly related to #151075):by-value-self-argument-in-trait-impl.rscaptured-fields-2.rscoroutine-locals.rslexical-scope-in-if-let.rsvar-captured-in-nested-closure.rsvar-captured-in-sendable-closure.rsvar-captured-in-stack-closure.rs
Weird/wrong location information in general/Shadowing issues:
dummy_span.rslexical-scope-in-stack-closure.rslexical-scope-in-unconditional-loop.rslexical-scope-in-if.rslexical-scope-with-macro.rs(error: Couldn't materialize: couldn't get the value of variable b: variable not available error: errored out in virtual lldb_private::LLVMUserExpression::DoExecute, couldn't PrepareToExecuteJITExpression)lexical-scope-in-unique-closure.rslexical-scope-in-for-loop.rslexical-scope-in-while.rslexical-scopes-in-block-expression.rsname-shadowing-and-scope-nesting.rsshadowed-variable.rsshadowed-argument.rssimple-lexical-scope.rs
LLDB ignoring ZSTs? (I think this is built in to their PDB parsing but i need to double check. This isn't a huge issue since nothing is failing on LLDB's end, it's just an annoying target-specific difference, so it resolves itself with
lldb-repr):issue-22656.rs
Gnu providers differ from MSVC (solves itself with
lldb-repr, but we should try to unify as much as possible):pretty-slices.rspretty-std-collections.rsvec-slices.rs(Also small broken visualizer forempty)
Broken visualizer:
strings-and-strs.rs-Rc<str>, readsRcInner<str>wide ptr as cstring and reads oob memory until it hits a null byte. Fixed whenever I get around to writing the generic wideptr visualizer
Oh no:
tuple-struct.rs-{0:-10008, 1:10009, 2:10010, 3:10011}reordered to{0:10011, 1:10010, 2:-10008, 3:10009}but notice how the field names are wrong relative to the source code definition of the struct 🫠
Other:
thread-names.rs#win- might need to use ascriptcommand to poll for any thread with the proper name, since i don't think thread 2 is guaranteed to be the one we spawned
- added 7 commits that reference this issue
on Aug 25, 2026 - added a commit that references this issue
on Aug 25, 2026 - added a commit that references this issue
on Aug 26, 2026 - added a commit that references this issue
on Aug 31, 2026 14 remaining items
Alrighty, the remainder of the test failures have 2 root causes. The tl;dr is half should probably be disabled, the other half need to be gated behind
23.1.0.-
Shadowing - when printing shadowed variables, on msvc it always prints the outer-most instance of the variable. That behavior matches Visual Studio, and it's not entirely clear when or if it'll be fixed on LLDB's end (see: [LLDB] Shadowed variable printing behavior differs with PDB vs DWARF debug info llvm/llvm-project#221696)
-
<no location, value may have been optimized out>- Here's a snippet of the PDB output fromcapture-fields2.rsusingllvm-pdbutil dump --symbolswith LLVM 22.1.8:
1164 | S_LOCAL [size = 28] `my_ref__my_field1` type=0x0075 (unsigned), flags = none 1192 | unknown (4471) [size = 24]That
unknownmeans LLVM doesn't know how to read the CodeView node that lives at that offset. Here's that same snippet, but using LLVM 23.1.0:1164 | S_LOCAL [size = 28] `my_ref__my_field1` type=0x0075 (unsigned), flags = none 1192 | S_DEFRANGE_REGISTER_REL_INDIR [size = 24] register = RSP, offset = 40, offset in udt = 0, offset in parent = 0, has spilled udt = false range = [0001:0150,+20), gaps = []S_DEFRANGE_REGISTER_REL_INDIRis basically a node that describes which physical memory the variable occupies, and for what instruction-range the variable is valid. The more commonly used variant isS_DEFRANGE_FRAMEPOINTER_REL, which, as the name would imply, is relative to the frame pointer rather than a pointer contained in a register.Support for
S_DEFRANGE_REGISTER_REL_INDIRwas added in march this year (and that PR didn't even enable its output, that must have come later).@Kobzol I haven't run the bisect, but presumably, at some point in the past few months, rustc started using a version of LLVM that outputs this node, even though LLDB couldn't read it until 23.1.0 (which didn't release until like 2 weeks ago). I also confirmed that my 1.98 toolchain outputs
S_DEFRANGE_REGISTER_REL_INDIR.-
Yes, we switched to LLVM 23(.1) in July.
If that sort of thing happened in the future and the tests catch it, would it be grounds to delay updating rustc's llvm until the official release and/or providing some kind of warning to those upgrading their toolchain? Breaking local variable debugging in a bunch of places on msvc for every non-prerelease version of LLDB seems not great
Support for
S_DEFRANGE_REGISTER_REL_INDIRwas added in march this year (and that PR didn't even enable its output, that must have come later).The generation of that record was added in https://redirect.github.com/llvm/llvm-project/pull/187709 (relanded in https://redirect.github.com/llvm/llvm-project/pull/189401). The motivation for Rust should be similar to C++ – with this change, the CodeView debug info can express the location of
my_var__my_field2(*(my_var+40) + 4). This wasn't possible before.If that sort of thing happened in the future and the tests catch it, would it be grounds to delay updating rustc's llvm until the official release and/or providing some kind of warning to those upgrading their toolchain? Breaking local variable debugging in a bunch of places on msvc for every non-prerelease version of LLDB seems not great
I doubt that we would block an LLVM update on waiting for debuggers to catch up, tbh. If there was a workaround though, then we would likely apply it.
Correction, rust 1.98 does not output
S_DEFRANGE_REGISTER_REL_INDIR, which is good. I was worried 1.98 released with, at the time, beta LLVM features 😅. I think I had a vestigial+nightly-msvcin mylaunch.json.It looks like 1.99 will be the first toolchain with llvm 23? It seems like a good idea to warn people about it though. I don't think there's a workaround on our end, and it makes captured closure variables completely uninspectable in LLDB <23.
That's kind of what we were discussing previously, that we more or less have to support only one LLDB version per Rust version? Or use workarounds to coerce LLVM into generating stuff that works with older LLDBs.
On the testing side, this is a pretty easy
//@ [msvc] min-llvm-lldb-version: 23.1.0. I more mean that if we know old LLDB versions will have major deficiencies in certain circumstances with the new toolchain, we should communicate it to the end-users in like the 1.99 release notes or something.Right, if we know in advance, and the regression is bad, it might indeed be useful to add this to release notes. I'm not sure if we have a place to add these "heads-up" warnings about tooling though (or if should be a one-off text mention). I'll ask on Zulip.
I plan on cleaning these up whenever I get the chance. This is a blocker for enabling LLDB debuginfo tests in CI.
The test failures are: