[Debuginfo] Force enum DISCR_* to static const u64 to allow for inspection via LLDB

[Walnut356]

see here for more info.

This change mainly helps *-msvc debugged with LLDB. Currently, LLDB cannot inspect static struct fields, so the intended visualization for enums is only borderline functional, and niche enums with ranges of discriminant cannot be determined at all .

LLDB can inspect static const values (though for whatever reason, non-enum/non-u64 consts don't work).

This change adds the LLVMRustDIBuilderCreateQualifiedType to the rust FFI layer to wrap the discr type with a const modifier, as well as forcing all generated integer enum DISCR_* values to be u64's. Those values will only ever be used by debugger visualizers anyway, so it shouldn't be a huge deal, but I left a fixme comment for it just in case.. The tag also still properly reflects the discriminant type, so no information is lost.

[rustbot]

r? @cjgillot

rustbot has assigned @cjgillot.
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

[workingjubilee]

Please git-clang-format this.

@rustbot author

[Zalathar]

To format the C++ code automatically, you should be able to do:

./x test tidy --extra-checks=cpp:fmt --bless

[workingjubilee]

@Walnut356 Just to check, there's no debuginfo api in the LLVM C API, right?

[workingjubilee]

can we file a bug for this against lldb? I think they don't have a separate repo from llvm, so it would just be against https://github.com/llvm/llvm-project

[Walnut356]

i've opened an issue for it llvm/llvm-project#119101

[Zalathar]

@Walnut356 Just to check, there's no debuginfo api in the LLVM C API, right?

At a glance it looks like there is debuginfo stuff in the LLVM C API, but we currently don't use any of it.

[Walnut356]

@Walnut356 Just to check, there's no debuginfo api in the LLVM C API, right?

If i'm understanding your question correctly, everything prefixed by LLVMDI is purely debug info generation. There's a handful of things it's used for currently, but we're definitely not taking full advantage of it.

[workingjubilee]

Oh, I somehow managed to miss this header?

https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm-c/DebugInfo.h

I see.

Ah, here we go: https://llvm.org/docs/doxygen/group__LLVMCCoreDebugInfo.html#ga8780f2c20339b37b01f8878401f27d00

[jieyouxu]

Also, is there a way to add a debuginfo test for this, to catch changes in the output?

[workingjubilee]

Well, since we currently use the C++ API for debuginfo it seems, you don't have to use the C API version of this function. I can't imagine it's trivial to make that interoperate with our current C++-using handling of debuginfo.

It would be better to do that port as its own PR, so I created an issue for it.

• Revamp cg_llvm debuginfo handling to use the LLVM-C API #134001

[Walnut356]

Also, is there a way to add a debuginfo test for this, to catch changes in the output?

At the moment, I don't think so. Debuginfo tests in CI currently only run on macos, whose output shouldn't change at all after these changes. There's also the problem that debug info is generated slightly differently for DAWRF vs PDB (afaik mostly due to the requirements of the formats themselves). As such, the tests would need to be written in a platoform-agnostic way, or they would need to have separate tests per platform. I haven't looked too much into how the test runner functions so i'm not sure how possible that is, but it fixing up the test suite is a priority for those of us working on debug info

[Walnut356]

@rustbot review

[workingjubilee]

@Walnut356 Hello! Squashy squashy?

[workingjubilee]

@bors r+

[bors]

📌 Commit a1191e3 has been approved by workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit a1191e3 with merge 3dc3c52...

[bors]

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 3dc3c52 to master...

[rust-timer]

Finished benchmarking commit (3dc3c52): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -7.3%, secondary -0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.4%, 2.4%]	1
Improvements ✅ (primary)	-7.3%	[-7.3%, -7.3%]	1
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	2
All ❌✅ (primary)	-7.3%	[-7.3%, -7.3%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 763.656s -> 763.423s (-0.03%)
Artifact size: 325.61 MiB -> 325.64 MiB (0.01%)