Enable LLDB debug info tests on CI by EFanZh · Pull Request #141539 · rust-lang/rust (original) (raw)

I've been attempting to run these tests on windows and there's a couple of things I noticed on *-windows-gnu:

• no attempt is made to match the python version that runs lldb_batchmode.py and the internal python version of LLDB. This is important because import lldb eventually imports _lldb.pyd - called _lldb.cp310-win_amd64.pyd the current llvm distribution at time of writing - which is essentially a .dll containing the bridge layer between python and C++. _lldb is compiled against a specific version of python, so if you use the wrong version you end up getting missing module errors for every test.
• Compilerun does not use the correct path separator for windows (: instead of ;), meaning if PYTHONPATH already has a value, the lldb module path isn't appended correctly.
• When running uv run --python 3.10.11 x.py test tests\debuginfo\basic-types.rs with the above fixes, LLDB reports an unknown error when trying to run the test executables. Trying to run the file myself reveals that Windows is unable to locate a dll file:

Adding .\build\x86_64-pc-windows-gnu\stage1\lib\rustlib\x86_64-pc-windows-gnu\lib to PATH allows the test to run properly. If testing *-windows-msvc as well, .\build\x86_64-pc-windows-gnu\stage1\lib\rustlib\x86_64-pc-windows-msvc\lib must also be included in PATH

I would investigate *-windows-msvc more, but but any attempt to compile core (seemingly core_builtins?) with build.build = "x86_64-pc-windows-msvc" in my bootstrap.toml fails via segfault.

I'm not super familiar with GDB, but lldb does come with a bundled CPython interpreter. There are also facilities to add custom commands. It may be worth running the test script inside of lldb itself rather than using a script that depends on it so that the ambient python version is no longer an issue. At the very least though there should be warnings if the user's python version doesn't match with lldb's internal python version.

Building/including pre-built lldb in the bootstrap process seems like the simplest solution. Otherwise, enforcing a minimum lldb version would work too. LLVM itself makes pre-built distributions for Windows now, so pointing people there if they have a too-old version could also work.

As for the actual test changes in this PR, a common theme is including the type name of the variable. This probably should not be done for lldb. The issue is, *-msvc generates different type names than *-gnu (e.g. (i32, i64) vs tuple$<i32, u64>) to work within the bounds of microsoft's tooling. Technically there's a way to work around that via the visualizer scripts, but it requires recursive string manipulation that's really finicky and I haven't had the time to test it properly.

On a related note, now that the debugger visualizer files are distributed with *-msvc toolchains, there definitely needs to be a pass to ensure the output of *-msvc visualizers matches *-gnu visualizers. When I wrote the *-msvc ones I was trying to hit a middle-ground between the existing ones and the ones that used to come bundled with CodeLLDB so they aren't 1:1 iirc. I don't think either set is inherently better or worse than the other, so it might be good to have some sort of discussion about what output would be preferred.