-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass 128-bit C-style enum enumerator values to LLVM #102717
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon. Please see the contribution instructions for more information. |
This probably fixes #100612? If so, can you add the regression test mentioned in the bug report? |
Unfortunately it does not: the ICE in #100612 is caused by the panic here in the code handling enums that have variants with fields, whereas this PR is for the code handling enums without any fields (C-style enums). While it is currently possible to pass the full 128 bits to LLVM for enums with fields too, LLVM currently truncates the discriminants of variants in debuginfo to 64 bits here, whereas C-style enumerators are not truncated by LLVM when emitting DWARF. |
I see. It would be helpful though to have some kind of test. |
I agree, however I'm not sure what the best way to test it is. While this PR means that the DWARF is correctly emitted, neither of the two DWARF debuggers that are currently tested support 128-bit enums, with GDB stating |
Makes sense. I guess one can do as you suggest. IDK a test is not that important, but having one would still be preferable so that nothing regresses. |
I've added a |
@beetrees thanks for that! |
6fa3354
to
6f6eebd
Compare
I've updated the PR to remove an outdated comment. |
Not my area of expertise r? rust-lang/compiler |
Not really mine either. r? compiler |
This looks right to me, but anyone from @rust-lang/wg-llvm can comment on the validity of the code? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice cleanup too!
$(RUSTC) -Cdebuginfo=2 lib.rs -o $(TMPDIR)/repr128.rlib | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n U128A $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )" | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n U128B $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )" | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n U128C $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 )" | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n U128D $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff )" | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n I128A $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )" | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n I128B $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff )" | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n I128C $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 )" | ||
"$(LLVM_BIN_DIR)"/llvm-dwarfdump -n I128D $(TMPDIR)/repr128.rlib | $(CGREP) "DW_AT_const_value (<0x10> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 7f )" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than this (or in addition to this) lets add a debuginfo test instead. It doesn't matter particularly much what dwarfdump
outputs if it turns out that the primary consumers of this data (gdb
/lldb
/other debuggers) can’t really stomach this kind of data anyway. E.g. if those “just” crash, then perhaps the ecosystem just isn’t ready for this and we probably shouldn't be stabilizing this feature either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gdb
and lldb
don't currently crash, but neither give any useful output that could be tested for (gdb
gives a nice error message instead of the current value of the enum-typed variable, lldb
prints an internal assertion error and doesn't correctly process the enum-typed variable in question but otherwise keeps going). This problem with debuggers can already be exposed using stable rustc
with a variable of type Option<NonZeroU128>
, which has a 128-bit discriminant (gdb
gives the same error message, lldb
doesn't support enums with fields at all).
Since gdb
and lldb
don't currently support 128-bit enums, this test seems like the best option to make sure the DWARF output doesn't break. I agree that once gdb
or lldb
gain support for 128-bit enums, this test should be replaced with a regular debuginfo test.
@@ -2118,7 +2118,8 @@ extern "C" { | |||
Builder: &DIBuilder<'a>, | |||
Name: *const c_char, | |||
NameLen: size_t, | |||
Value: i64, | |||
Value: *const u64, | |||
SizeInBits: c_uint, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to prefer c_uint
over u64
like in the function above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unsigned int
is the type of the SizeInBits parameter of the APInt
constructor on the C++ side; using c_uint
here means any integer truncation is visible on the Rust side rather than buried in the C++ wrapper (this shouldn't matter in practice as the maximum value of SizeInBits
here is 128). I'm happy to change it to u64
if you think that would be an improvement, but using c_uint
here seems like better design.
r? @nagisa |
@bors r+ Thanks! |
@bors rollup=never |
⌛ Testing commit 6f6eebd with merge dd0fe1b3541ae0002b29fa12c9138e2d44a5b662... |
💔 Test failed - checks-actions |
@bors retry network error |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ccde51a): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
|
This is recent |
…r=nagisa Pass 128-bit C-style enum enumerator values to LLVM Pass the full 128 bits of C-style enum enumerators through to LLVM. This means that debuginfo for C-style repr128 enums is now emitted correctly for DWARF platforms (as compared to not being correctly emitted on any platform). Tracking issue: rust-lang#56071
Pass the full 128 bits of C-style enum enumerators through to LLVM. This means that debuginfo for C-style repr128 enums is now emitted correctly for DWARF platforms (as compared to not being correctly emitted on any platform).
Tracking issue: #56071