Add Natvis visualiser and debuginfo tests for f128

[beetrees]

View all comments

To render f128s in debuggers on MSVC targets, this PR changes the compiler to output f128s as struct f128 { low_bits: u64, high_bits: u64 }, and includes a Natvis visualiser that displays the float in hexdecimal format (similar to the LowerHex impl in #160626), as unlike f16 there's no larger supported float format to convert to and trying to write a float to decimal string converter in Natvis didn't seem practical. gdb, lldb and cdb tests are also included for f128, although gdb does not yet correctly identify the float format.

I did consider also displaying a double approximation of the f128 (as the debugger will convert that to a decimal string) but decided against it as f64 has a significantly smaller exponent range too (meaning very large or small f128s couldn't have an approximation anyway) and cdb and WinDbg both seem to round all floating-point numbers to 6 decimal places, meaning the displayed number is (double) rounded even further than f64 precision and is useless for tiny values.

Closes #121837
Tracking issue: #116909

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
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: compiler
• compiler expanded to 75 candidates
• Random selection from 16 candidates

[beetrees]

cc MSVC target maintainers: @ChrisDenton @dpaoliello @Fulgen301 @lambdageek @sivadeilra @wesleywiser

[beetrees]

(Given this touches debuginfo tests this should probably get a bors try x86_64-msvc-* i686-msvc-* aarch64-msvc-* aarch64-apple-*.)

[folkertdev]

@bors try jobs=x86_64-msvc-,i686-msvc-,aarch64-msvc-,aarch64-apple-

[folkertdev]

@bors try jobs=x86_64-msvc-,i686-msvc-,aarch64-msvc-,aarch64-apple-

[rust-bors]

💔 Test for 816a2f0 failed: CI. Failed jobs:

• try - aarch64-apple-1 (web logs, enhanced plaintext logs)
• try - aarch64-apple-macos-26-1 (web logs, enhanced plaintext logs)

[beetrees]

According to the table on Wikipedia, there isn't any Xcode versions yet with LLDB 22 or later, so I've ignored the f128 debuginfo tests on Apple for now and left a FIXME.

[folkertdev]

@bors try jobs=x86_64-msvc-,i686-msvc-,aarch64-msvc-,aarch64-apple-

[rust-bors]

☀️ Try build successful (CI)
Build commit: d79cce8 (d79cce855e6f305d9b8796f97b79e09fb0a5c022)
Base parent: 3ffb26f (3ffb26fbf5bf232cf59e314e75ea325973f4f583)

[beetrees]

@rustbot review

[JohnTitor]

Looks good! I'm not going to r+ just in case you want to wait for another look from the target maintainers. Ohterwise r=me

View changes since this review

[beetrees]

I've updated the LLDB tests that this PR adds in basic-types-mut-globals.rs to match the changes made to the existing ones in basic-types-globals.rs in the rebase. Not sure if this counts as significant enough to require a review or if the r=me still stands, so I'll air on the side of caution.

[rustbot]

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.

[folkertdev]

cc @Walnut356 because debug info (and debug experience)

[Walnut356]

I'll give this a look later today

[Walnut356]

Just a heads up for reviewers, the tests passing in CI should not be considered reliable w.r.t. debuginfo changes at all. Iirc only GDB is tested in PR CI, and the only bors tests i'm 100% sure of are lldb on aarch64-apple, gdb on linux, and probably cdb on windows. It's safer (and probably correct) to assume that nothing else is tested by CI.

The windows LLDB tests only fully pass when run locally as of a few days ago, so at this point running them yields meaningful results (keep in mind lldb/gdb debuginfo tests are opt-in now). I'm working on getting more CI runners to run the debuginfo tests, but right now it is what it is.

---

Running the tests locally on x86_64-pc-windows-msvc with lldb 22, i had 6 LLDB test failures. Based on the output, it's because the test data is based on lldb being able to natively handle float128, so making rustc output a struct makes lldb never invoke the native handling.

I need to probably change the names/doc comments of is_msvc and cpp_like_debuginfo. They're ambiguous enough to make it seem like they can mean is_cdb, but they're roundabout ways of saying is_pdb_debuginfo. Since LLDB can handle pdb debuginfo too, any changes that affect PDB as a whole need to account for both debuggers.

There's a couple of options:

• ideally (assuming natvis cooperates), we could not generate the struct debuginfo, and instead have natvis cast the float128 to an unsigned __int64[2] or 2 u64 pointers or whatever, and use those to generate the same summary this PR adds. I dont have a ton of experience writing natvis scripts, but the expression parsing is pretty robust so iirc it should be doable.
• (i'm not super fond of this option) we do generate f128 as a struct, but write lldb visualizers to cast it to a float128

[beetrees]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[beetrees]

ideally (assuming natvis cooperates), we could not generate the struct debuginfo, and instead have natvis cast the float128 [...]

Unfortunately this doesn't work: I've checked again just now and WinDbg just gives a "Type information missing error" which appears to make it impossible to even match on the type name in Natvis. I'll do something similar to what you did for f16 in #161721.

[beetrees]

I've tested LLDB on Windows manually and the summary provider I've added works, but I was unable to test LLDB via x test tests/debuginfo on Windows as LLDB kept emitting error: invalid target, create a target using the 'target create' command, despite x test tests/debuginfo working fine for LLDB on Linux; I haven't been able to work out what the problem is as the debugger test python script explicitly creates a target before running the test. @Walnut356 could you run the LLDB debuginfo tests on Windows again and see if everything passes now?

@rustbot review

[Walnut356]

Hmm, that's probably an LLDB version issue. We havent gotten to gating everything to a single LLDB version yet, but the only versions we're even attempting to support atm are 21 and 22. lldb 23 very likely doesnt work atm. relevant part:

One note, LLDB 23 seems to like it even less when we use the parent debugger instance for the test harness. I'll fix that in a followup PR since it requires a little bit of fiddling to get it to work with LLDB <23 (the short version is it's much harder to exit with a non-0 status code when using a nested debugger instance. We should be able to run something like os.kill(os.getpid(), signal.SIGTERM) from the internal python to kill the parent LLDB process to work around that)

[Walnut356]

Small nit, PDB does have a node for 128-bit floats. It's the (very memorable) tag value 0x8008 =) (CodeView spec for reference)

I did a sanity check earlier to be sure. Rustc asks LLVM for it properly and LLVM creates it properly, it's just that microsoft's debuggers don't have support for it (nor do they have a builtin type we can leech off of like __int128). I wish i could say this is the only one of their own nodes they don't support, but unfortunately they don't handle typedefs correctly either 🫠

View changes since the review

[beetrees]

I've updated the comments to say that most Windows debuggers don't support PDB f128.

[beetrees]

Hmm, that's probably an LLDB version issue.

Got it working with LLDB 22. All debuginfo tests now pass for LLDB on x86_64-pc-windows-msvc.