about summary refs log tree commit diff
path: root/compiler/rustc_codegen_gcc/src/coverageinfo.rs
diff options
context:
space:
mode:
authorJubilee <workingjubilee@gmail.com>2025-02-13 17:46:08 -0800
committerGitHub <noreply@github.com>2025-02-13 17:46:08 -0800
commit864eba9fb13d1f732e16a4fb1ca9846a5757f1c5 (patch)
tree89b447676036a9442175d4490aa1824b8c29fd23 /compiler/rustc_codegen_gcc/src/coverageinfo.rs
parentd784803115ee2226e22d10f7ad6dede618aa8dd7 (diff)
parentd82219a4fa06bfa47fc5aac64844c461905ae77d (diff)
downloadrust-864eba9fb13d1f732e16a4fb1ca9846a5757f1c5.tar.gz
rust-864eba9fb13d1f732e16a4fb1ca9846a5757f1c5.zip
Rollup merge of #136895 - maurer:fix-enum-discr, r=nikic
debuginfo: Set bitwidth appropriately in enum variant tags

Previously, we unconditionally set the bitwidth to 128-bits, the largest an enum would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit enumerators, so this would also have occasionally resulted in truncated data.

LLVM added support for 128-bit enumerators in llvm/llvm-project#125578

That patchset trusts the constant to describe how wide the variant tag is, so the high 64-bits of zeros are considered potentially load-bearing.

As a result, we went from emitting tags that looked like:
DW_AT_discr_value     (0xfe)

(because `dwarf::BestForm` selected `data1`)

to emitting tags that looked like:
DW_AT_discr_value	(<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 )

This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which:
1. Is probably closer to our intentions in terms of describing the data.
2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools.
3. Will result in smaller debug information.
Diffstat (limited to 'compiler/rustc_codegen_gcc/src/coverageinfo.rs')
0 files changed, 0 insertions, 0 deletions