Debuginfo tests don't control for ambient tools #126092
Comments
rustbot
added
the
needs-triage
workingjubilee
added
A-testsuite
|
The debuginfo test suite should also be insulated against gdb changing how it prints things, Because It Does. |
|
Some points:
|
|
That's... informative, thank you! It does seem like we should reassess our strategy if we're gonna run a test suite that isn't guaranteed to pass even between different versions of a debugger on "any ol' random debugger lying around". |
|
On macOS we can't ship our own debugger. Only an Apple signed lldb is allowed to use the debugging apis of the kernel. |
|
Wait, gdb is useless on macOS? |
|
Supposedly you can use gdb on macOS jf you sign it with a self-signed code signing certificate which you add to the system keychain, mark as trusted for code signing and set the right entitlements when signing gdb. I don't know if you need to disable SIP for this to work though. We can't disable SIP on CI. https://dev.to/jasonelwood/setup-gdb-on-macos-in-2020-489k |
|
Hmm, okay. I think on Linux it is still desirable to control for the sheer amount of variability that Linux distros have, but I can believe that the debuginfo tests have to draw on the environment sometimes. |
|
I think it's fine if we can't necessarily control for the debugger used, but we should at least document it and/or report the debugger used when running the debuginfo test suite. |
|
yeah, that was also reported as #126628 |
|
FYI all of the lldb tests have been failing for anyone who uses a rolling distro for the past 8 months because of llvm/llvm-project#70453 |
|
In case anyone stumbled across this, IIRC lldb debuginfo tests (currently) require Python 3.10 dll to be present in |
jieyouxu
added
E-medium
|
this has come back to bite us in #133107 |
|
i think we should consider the version of the debugger to be part of the "prerequisites" compiletest uses to determine whether to run the test at all (see #126628). it doesn't make any sense to run a test that needs lldb 19 against lldb 12. |
I think there are two parts to this:
|
…r=Mark-Simulacrum Add LLDB providers for BTreeMap and BTreeSet Fixes rust-lang#111868. I'm unsure what the supported LLDB versions for `rust-lldb` are. I tested with LLDB 18 and 19 and it works with those but I know that it does not work with LLDB 14 which was picked by my `codelldb` extension for some reason (even though it packages LLDB 19). I also had to work around what seems like an LLDB bug to me. Otherwise, I'd have kept the code more similar to the GDB provider. `SBTarget.FindFirstType()` does not find the types that I'm searching for (`LeafNode<i32, i32>*`): ``` target = node.GetTarget() print("leaf type:", node.GetType()) internal_type = target.FindFirstType(node.GetType().GetName()) print("Actual type:", internal_type) ``` which prints ``` leaf type: struct alloc::collections::btree::node::LeafNode<int, int> * Actual type: No value ``` All in all, my experience with LLDB debug provider was very fiddly/they seem to break easily but I think it would be better to have `BTreeMap`/`BTreeSet` providers than not have them. Getting to run the `debuginfo` tests was a pain too because of rust-lang#126092 and errors with `import _lldb` (rust-lang#123621). I ended up re-compling lldb from source against python 3.10 because the tests don't work if lldb is compiled against python 3.12. Also, it seems like the tests are not run in CI? At least I had a test commit in the PR before to trigger a `debuginfo` test failure which I didn't see here in my PR.
The debuginfo tests should probably use a specific debugger, like maybe an lldb we build with the compiler, so that they work consistently. In practice, they have been effectively broken on user's machines by just trying to use whatever is installed.
In other words: just because I use Linux doesn't mean I have gdb installed.
The text was updated successfully, but these errors were encountered: