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

Fix DWARF generation for enums #54004

Merged
merged 8 commits into from Oct 31, 2018

Conversation

Projects
None yet
10 participants
@tromey
Contributor

tromey commented Sep 6, 2018

The DWARF generated for Rust enums was always somewhat unusual.
Rather than using DWARF constructs directly, it would emit magic field
names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR". Since
PR #45225, though, even this has not worked -- the ad hoc scheme was
not updated to handle the wider variety of niche-filling layout
optimizations now available.

This patch changes the generated DWARF to use the standard tags meant
for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part.

The patch to implement this went in to LLVM 7. In order to work with
older versions of LLVM, and because LLVM doesn't do anything here for
PDB, the existing code is kept as a fallback mode.

Support for this DWARF is in the Rust lldb and in gdb 8.2.

Closes #32920
Closes #32924
Closes #52762
Closes #53153

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Sep 6, 2018

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

&layout::Variants::NicheFilling { ref niche, .. } => {
// Find the integer type of the correct size.
let discr_type = niche.value.to_ty(cx.tcx);

This comment has been minimized.

@eddyb

eddyb Sep 6, 2018

Member

You can get the size and alignment from niche.value directly.

16 => Integer::I16,
32 => Integer::I32,
64 => Integer::I64,
bits => bug!("prepare_enum_metadata: unknown niche bit size {}", bits),

This comment has been minimized.

@eddyb

eddyb Sep 6, 2018

Member

Is there no method on Integer to do this conversion?

This comment has been minimized.

@tromey

tromey Sep 7, 2018

Contributor

Not directly (that I could find) but I can use Integer::fit_unsigned.

This comment has been minimized.

@eddyb

eddyb Sep 7, 2018

Member

Oh, I think you should match on Primitive, convert floats to I32 / I64, and pointers to cx.data_layout().ptr_sized_integer(). That way you don't need to turn an integer back into itself by looking at its size.

@nagisa

This comment has been minimized.

Contributor

nagisa commented Sep 6, 2018

This definitely wants a test or two.

EDIT: though I won’t block this PR if they aren’t easy to write.

@eddyb

r=me with nits fixed

@eddyb

This comment has been minimized.

Member

eddyb commented Sep 6, 2018

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Sep 6, 2018

r? @eddyb

(I pinged him on Discord as I'm not really that familiar with this code. But I see he already left a review before I came back to re-assign. I agree with @nagisa that we could use more tests here :)

@rust-highfive rust-highfive assigned eddyb and unassigned nikomatsakis Sep 6, 2018

@tromey

This comment has been minimized.

Contributor

tromey commented Sep 6, 2018

I can write more tests but note that there are existing debuginfo tests that already cover the ordinary cases. The new test is testing the case that could not be made to work previously.

@rust-highfive

This comment was marked as outdated.

Collaborator

rust-highfive commented Sep 6, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:50:46] ....................................................................................................
[00:50:50] ....................................................................................................
[00:50:52] ................................i...................................................................
[00:50:55] ....................................................................................................
[00:50:58] .................................................................................iiiiiiiii..........
[00:51:04] ...ii...............................................................................................
[00:51:08] ....................................................................................................
[00:51:11] ..............................................................i.....................................
[00:51:14] ....................................................................................................
---
[00:51:45] ........................................................................................i...........
[00:51:48] ....................................................................................................
[00:51:52] ....................................................................................................
[00:51:54] ....................................................................................................
[00:51:57] .i.ii.ii..ii............................i...........................................................
[00:51:57] test result: ok. 4137 passed; 0 failed; 64 ignored; 0 measured; 0 filtered out
[00:51:57] 
[00:51:57]  finished in 127.128
[00:51:57] travis_fold:end:test_ui_nll
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-gdb (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:58:39] 
[00:58:39] running 110 tests
[00:58:51] iiii.....F.i..i........i..i.i...F.....F..Fi..........iiii...........i....i..........ii.i.i...F...ii.
ne at:
[00:58:51] <http://www.gnu.org/software/gdb/documentation/>.
[00:58:51] For help, type "help".
[00:58:51] Type "apropos word" to search for commands related to "word".
[00:58:51] Breakpoint 1 at 0xb12: file /checkout/src/test/debuginfo/borrowed-enum.rs, line 81.
[00:58:51] [Thread debugging using libthread_db enabled]
[00:58:51] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[00:58:51] 
[00:58:51] Breakpoint 1, borrowed_enum::main::hfdf2cbe4fde99803 () at /checkout/src/test/debuginfo/borrowed-enum.rs:81
[00:58:51] 81     zzz(); // #break
[00:58:51] $1 = {TheA = {RUST$ENUM$DISR = TheA, x = 0, y = 8970181431921507452}, TheB = {RUST$ENUM$DISR = TheA, __0 = 8970181431921507452, __1 = 32767, __2 = 0}}
[00:58:51] $2 = {TheA = {RUST$ENUM$DISR = TheB, x = 140733479719185, y = 0}, TheB = {RUST$ENUM$DISR = TheB, __0 = 0, __1 = 286331153, __2 = 286331153}}
[00:58:51] $3 = {TheOnlyCase = {__0 = 4820353753753434}}
[00:58:51] A debugging session is active.
[00:58:51] 
[00:58:51]  Inferior 1 [process 14603] will be killed.
[00:58:51] 
[00:58:51] Quit anyway? (y or n) [answered Y; input not from terminal]
[00:58:51] ------------------------------------------
[00:58:51] stderr:
[00:58:51] ------------------------------------------
[00:58:51] 
---
[00:58:51] 
[00:58:51] ---- [debuginfo-gdb] debuginfo/generic-enum-with:58:51] 
[00:58:51] thread '[debuginfo-gdb] debuginfo/generic-enum-with-different-disr-sizes.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3196:9
[00:58:51] 
[00:58:51] ---- [debuginfo-gdb] debuginfo/generic-struct-style-enum.rs stdout ----
[00:58:51] NOTE: compiletest thinks it is using GDB without native rust support
[00:58:51] NOTE: compiletest thinks it is using GDB version 7011001
[00:58:51] 
[00:58:51] error: line not found in debugger output: $1 = {{RUST$ENUM$DISR = Case1, a = 0, b = 31868, c = 31868, d = 31868, e = 31868}, {RUST$ENUM$DISR = Case1, [...]}, {RUST$ENUM$DISR = Case1, [...]}}
[00:58:51] status: exit code: 0
[00:58:51] command: "/usr/bin/gdb" "-quiet" "-batch" "-nx" "-command=/checkout/obj/build/x86_64-unknown-linux-gnu/test/debuginfo/generic-struct-style-enum/generic-struct-style-enum.debugger.script"
[00:58:51] ------------------------------------------
[00:58:51] GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
[00:58:51] Copyright (C) 2016 Free Software Foundation, Inc.
[00:58:51] Copyright (C) 2016 Free Software Foundation, Inc.
[00:58:51] License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[00:58:51] This is free software: you are free to change and redistribute it.
[00:58:51] There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[00:58:51] and "show warranty" for details.
[00:58:51] This GDB was configured as "x86_64-linux-gnu".
[00:58:51] Type "show configuration" for configuration details.
[00:58:51] For bug reporting instructions, please see:
[00:58:51] <http://www.gnu.org/software/gdb/bugs/>.
[00:58:51] Find the GDB manual and other documentation resources online at:
[00:58:51] <http://www.gnu.org/software/gdb/documentation/>.
[00:58:51] For help, type "help".
[00:58:51] Type "apropos word" to search for commands related to "word".
[00:58:51] Breakpoint 1 at 0x9f7: file /checkout/src/test/debuginfo/generic-struct-style-enum.rs, line 86.
[00:58:51] [Thread debugging using libthread_db enabled]
[00:58:51] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[00:58:51] 
[00:58:51] Breakpoint 1, generic_struct_style_enum::main::h6baa2d814575bd09 () at /checkout/src/test/debuginfo/generic-struct-style-enum.rs:86
[00:58:51] 86     zzz(); // #break
[00:58:51] $1 = {Case1 = {RUST$ENUM$DISR = Case1, a = 0, b = 31868, c = 31868, d = 31868, e = 31868}, Case2 = {RUST$ENUM$DISR = Case1, a = 0, b = 2088533116, c = 4137712764}, Case3 = {RUST$ENUM$DISR = Case1, a = 140737331100796, b = 0}}
[00:58:51] $2 = {Case1 = {RUST$ENUM$DISR = Case2, a = 0, b = -2133, c = 4369, d = 4369, e = 4369}, Case2 = {RUST$ENUM$DISR = Case2, a = 0, b = 286331153, c = 286331153}, Case3 = {RUST$ENUM$DISR = Case2, a = 140733479719185, b = 0}}
[00:58:51] $3 = {Case1 = {RUST$ENUM$DISR = Case3, a = 6438275382588823897, b = 63405, c = 32767, d = 0, e = 0}, Case2 = {RUST$ENUM$DISR = Case3, a = 6438275382588823897, b = 32767, c = 0}, Case3 = {RUST$ENUM$DISR = Case3, a = 0, b = 6438275382588823897}}
[00:58:51] $4 = {TheOnlyCase = {a = -1}}
[00:58:51] A debugging session is active.
[00:58:51] 
[00:58:51]  Inferior 1 [process 15075] will be killed.
[00:58:51] 
[00:58:51] Quit anyway? (y or n) [answered Y; input not from terminal]
[00:58:51] 
[00:58:51] ------------------------------ug reporting instructions, please see:
[00:58:51] <http://www.gnu.org/software/gdb/bugs/>.
[00:58:51] Find the GDB manual and other documentation resources online at:
[00:58:51] <http://www.gnu.org/software/gdb/documentation/>.
[00:58:51] For help, type "help".
[00:58:51] Type "apropos word" to search for commands related to "word".
[00:58:51] Breakpoint 1 at 0x9f8: file /checkout/src/test/debuginfo/generic-tuple-style-enum.rs, line 104.
[00:58:51] [Thread debugging using libthread_db enabled]
[00:58:51] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[00:58:51] 
[00:58:51] Breakpoint 1, generic_tuple_style_enum::main::h0ff66a8041e01145 () at /checkout/src/test/debuginfo/generic-tuple-style-enum.rs:104
[00:58:51] 104     zzz(); // #break
[00:58:51] $1 = {Case1 = {RUST$ENUM$DISR = Case1, __0 = 0, __1 = 31868, __2 = 31868, __3 = 31868, __4 = 31868}, Case2 = {RUST$ENUM$DISR = Case1, __0 = 0, __1 = 2088533116, __2 = 4158487676}, Case3 = {RUST$ENUM$DISR = Case1, __0 = 140737351875708, __1 = 0}}
[00:58:51] $2 = {Case1 = {RUST$ENUM$DISR = Case2, __0 = 0, __1 = -2400, __2 = 4369, __3 = 4369, __4 = 4369}, Case2 = {RUST$ENUM$DISR = Case2, __0 = 0, __1 = 286331153, __2 = 286331153}, Case3 = {RUST$ENUM$DISR = Case2, __0 = 140733479719185, __1 = 0}}
[00:58:51] $3 = {Case1 = {RUST$ENUM$DISR = Case3, __0 = 6438275382588823897, __1 = -2131, __2 = 32767, __3 = 0, __4 = 0}, Case2 = {RUST$ENUM$DISR = Case3, __0 = 6438275382588823897, __1 = 32767, __2 = 0}, Case3 = {RUST$ENUM$DISR = Case3, __0 = 0, __1 = 6438275382588823897}}
[00:58:51] $4 = {TheOnlyCase = {__0 = -1}}
[00:58:51] A debugging session is ax-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-5.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:58:51] 
[00:58:51] 
[00:58:51] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:58:51] Build completed unsuccessfully in 0:12:16
[00:58:51] Build completed unsuccessfully in 0:12:16
[00:58:51] make: *** [check] Error 1
[00:58:51] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:06cbc26b
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:0e4653d4:start=1536264235832955119,finish=1536264235841468195,duration=8513076
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:11ebf6c4
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/core

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@tromey

This comment has been minimized.

Contributor

tromey commented Sep 7, 2018

Still investigating that failure. I'd tried things out with llvm 6 but not 5. I somewhat recall having to make a change here for 6; I will try all 3 ways again but if something has to regress, I think we should let it be 5.

@tromey

This comment has been minimized.

Contributor

tromey commented Sep 10, 2018

I built rust against LLVM 5, 6, and rust-llvm; and then I tested each one against gdb 7.11, 8.1, and 8.2.

This found a crash in 8.2, filed: https://sourceware.org/bugzilla/show_bug.cgi?id=23626. I'll fix this before 8.2.1.

I couldn't reproduce the bot's failure; but the bot is using 7.11, and my feeling is that a minor output regression there is nothing to worry about. So, if it persists and there are no objections, I'll just bump the minimum gdb version for the test.

@tromey

This comment has been minimized.

Contributor

tromey commented Sep 11, 2018

I couldn't reproduce the bot's failure

I rebased & tried again and now it failed.

@tromey

This comment has been minimized.

Contributor

tromey commented Sep 11, 2018

I rebased & tried again and now it failed.

At some point I thought I needed to give the variants names, but reverting this and re-testing didn't show any problems.

tromey added a commit to tromey/gdb that referenced this pull request Sep 11, 2018

Fix crash with empty Rust enum
While testing my Rust compiler patch to fix the DWARF representation
of Rust enums (rust-lang/rust#54004), I found
a gdb crash coming from one of the Rust test cases.

The bug here is that the new variant support in gdb does not handle
the case where there are no variants in the enum.

This patch fixes the problem in a straightforward way.  Note that the
new tests are somewhat lax because I did not want to try to fully fix
this corner case for older compilers.  If you think that's
unacceptable, let meknow.

Tested on x86-64 Fedora 28 using several versions of the Rust
compiler.  I intend to push this to the 8.2 branch as well.

gdb/ChangeLog
2018-09-11  Tom Tromey  <tom@tromey.com>

	PR rust/23626:
	* rust-lang.c (rust_enum_variant): Now static.
	(rust_empty_enum_p): New function.
	(rust_print_enum, rust_evaluate_subexp, rust_print_struct_def):
	Handle empty enum.

gdb/testsuite/ChangeLog
2018-09-11  Tom Tromey  <tom@tromey.com>

	PR rust/23626:
	* gdb.rust/simple.rs (EmptyEnum): New type.
	(main): Use it.
	* gdb.rust/simple.exp (test_one_slice): Add empty enum test.
@tromey

This comment has been minimized.

Contributor

tromey commented Sep 13, 2018

@eddyb can you re-review? I don't think I have sufficient permissions to mark it. Thanks.

@eddyb

This comment has been minimized.

Member

eddyb commented Sep 13, 2018

@tromey Is the compiler-builtins submodule change intentional?

None
} else {
Some((i.wrapping_sub(*niche_variants.start()) as u128)
.wrapping_add(niche_start) as u64)

This comment has been minimized.

@eddyb

eddyb Sep 13, 2018

Member

Hmm, I think if you do this then we're "insured" from weird 128-bit bugs:

let niche = (i as u128)
    .wrapping_sub(*niche_variants.start() as u128)
    .wrapping_add(niche_start);
assert_eq!(niche as u64 as u128, niche);
Some(niche as u64)

Note that other than the assert, you also had an overflow bug: if niche_variants.start() is larger than i, subtracting u64s and casting the "negative" result to u128 puts you close to 1 << 64 (because it zero-extends), instead of being a "negative" 128-bit integer.

file_metadata,
UNKNOWN_LINE_NUMBER,
enum_type_size.bits(),
enum_type_align.abi_bits() as u32,

This comment has been minimized.

@eddyb

eddyb Sep 13, 2018

Member

Hmm, do all variants use these size/alignment values? Because each variant has its own "sub-layout" that "fits" inside the enum's layout, and it might make more sense to use those individual ones. Also, instead of UNKNOWN_LINE_NUMBER, you can get each variant's declaration span.

This comment has been minimized.

@tromey

tromey Sep 13, 2018

Contributor

This part is just a bit of DWARF formalism. This is emitting a DW_TAG_variant_part, which according to DWARF is the part of an enclosing structure that can vary. For Rust, the entire thing can vary, so we emit a structure wrapping a variant part, which wraps the variants. Since there can only be one variant part, it makes sense for it to fill the enclosing structure. And, the location of this thing is unimportant as it is basically entirely artificial -- a synthetic construct only necessary because this is how DWARF mandates it.

This comment has been minimized.

@eddyb

eddyb Sep 13, 2018

Member

Ah, so it's not per-variant?

This comment has been minimized.

@tromey

tromey Sep 13, 2018

Contributor

Nope.

@tromey

This comment has been minimized.

Contributor

tromey commented Sep 13, 2018

@tromey Is the compiler-builtins submodule change intentional?

Nope.

@tromey tromey referenced this pull request Sep 13, 2018

Merged

Implement `MaybeUninit` #53508

wallento pushed a commit to wallento/binutils-gdb that referenced this pull request Sep 13, 2018

Fix crash with empty Rust enum
While testing my Rust compiler patch to fix the DWARF representation
of Rust enums (rust-lang/rust#54004), I found
a gdb crash coming from one of the Rust test cases.

The bug here is that the new variant support in gdb does not handle
the case where there are no variants in the enum.

This patch fixes the problem in a straightforward way.  Note that the
new tests are somewhat lax because I did not want to try to fully fix
this corner case for older compilers.  If you think that's
unacceptable, let meknow.

Tested on x86-64 Fedora 28 using several versions of the Rust
compiler.  I intend to push this to the 8.2 branch as well.

gdb/ChangeLog
2018-09-13  Tom Tromey  <tom@tromey.com>

	PR rust/23626:
	* rust-lang.c (rust_enum_variant): Now static.
	(rust_empty_enum_p): New function.
	(rust_print_enum, rust_evaluate_subexp, rust_print_struct_def):
	Handle empty enum.

gdb/testsuite/ChangeLog
2018-09-13  Tom Tromey  <tom@tromey.com>

	PR rust/23626:
	* gdb.rust/simple.rs (EmptyEnum): New type.
	(main): Use it.
	* gdb.rust/simple.exp (test_one_slice): Add empty enum test.

kraj pushed a commit to kraj/binutils-gdb that referenced this pull request Sep 13, 2018

Fix crash with empty Rust enum
While testing my Rust compiler patch to fix the DWARF representation
of Rust enums (rust-lang/rust#54004), I found
a gdb crash coming from one of the Rust test cases.

The bug here is that the new variant support in gdb does not handle
the case where there are no variants in the enum.

This patch fixes the problem in a straightforward way.  Note that the
new tests are somewhat lax because I did not want to try to fully fix
this corner case for older compilers.  If you think that's
unacceptable, let meknow.

Tested on x86-64 Fedora 28 using several versions of the Rust
compiler.  I intend to push this to the 8.2 branch as well.

2018-09-13  Tom Tromey  <tom@tromey.com>

	PR rust/23626:
	* rust-lang.c (rust_enum_variant): Now static.
	(rust_empty_enum_p): New function.
	(rust_print_enum, rust_evaluate_subexp, rust_print_struct_def):
	Handle empty enum.

gdb/testsuite/ChangeLog
2018-09-13  Tom Tromey  <tom@tromey.com>

	PR rust/23626:
	* gdb.rust/simple.rs (EmptyEnum): New type.
	(main): Use it.
	* gdb.rust/simple.exp (test_one_slice): Add empty enum test.
@eddyb

eddyb approved these changes Sep 13, 2018

@eddyb

This comment has been minimized.

Member

eddyb commented Sep 13, 2018

@bors r+

tromey added some commits Nov 29, 2017

Fix DWARF generation for enums
The DWARF generated for Rust enums was always somewhat unusual.
Rather than using DWARF constructs directly, it would emit magic field
names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR".  Since
PR #45225, though, even this has not worked -- the ad hoc scheme was
not updated to handle the wider variety of niche-filling layout
optimizations now available.

This patch changes the generated DWARF to use the standard tags meant
for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part.

The patch to implement this went in to LLVM 7.  In order to work with
older versions of LLVM, and because LLVM doesn't do anything here for
PDB, the existing code is kept as a fallback mode.

Support for this DWARF is in the Rust lldb and in gdb 8.2.

Closes #32920
Closes #32924
Closes #52762
Closes #53153
Address review comments
This fixes the issues pointed out in review.
Tighten enum-debug test
Update the new enum-debug to ensure that field "D" does not have a
discrimnant.
Add more enum debug info tests
Rename the previous enum debug info test, and add more tests to cover
c-like enums and tagged (ordinary) enums.
Avoid possible integer overflow in niche value computation
@eddyb pointed out in review that the niche value computation had a
possible integer overflow problem, fixed here as he suggested.
Update enum debuginfo tests
Bug #52452 notes some debuginfo test regressions when moving to gdb
8.1.  This series will also cause versions of gdb before 8.2 to fail
when a recent LLVM is used -- DW_TAG_variant_part support was not
added until 8.2.

This patch updates one of the builders to a later version of Ubuntu,
which comes with gdb 8.2.  It updates the relevant tests to require
both a new-enough LLVM and a new-enough gdb; the subsequent patch
arranges to continue testing the fallback mode.

The "gdbg" results are removed from these tests because the tests now
require a rust-enabled gdb.

If you read closely, you'll see that some of the lldb results in this
patch still look a bit strange.  This will be addressed in a
subsequent patch; I believe the fix is to disable the Python
pretty-printers when lldb is rust-enabled.
Add legacy debuginfo tests
The enum debuginfo patch includes a legacy mode that is used when
building against LLVM 5 and LLVM 6.  The main enum debuginfo tests
have been updated to rely on the new approach and a new-enough gdb.
This patch makes a copy of these tests so that the fallback mode will
continue to be tested.

Note that nil-enum.rs is not copied; it seemed not to provide enough
value to bother.

A new header directive is added, "ignore-llvm-version".  I will send a
patch to update the rustc documentation once this lands.
Update lldb
Update src/tools/lldb to pick up a needed bug fix in the
DW_TAG_variant_part handling.
@tromey

This comment has been minimized.

Contributor

tromey commented Oct 30, 2018

@bors r+

@bors

This comment has been minimized.

Contributor

bors commented Oct 30, 2018

📌 Commit 98b2688 has been approved by tromey

@bors

This comment has been minimized.

Contributor

bors commented Oct 30, 2018

⌛️ Testing commit 98b2688 with merge 0db7abe...

bors added a commit that referenced this pull request Oct 30, 2018

Auto merge of #54004 - tromey:enum-debuginfo, r=tromey
Fix DWARF generation for enums

The DWARF generated for Rust enums was always somewhat unusual.
Rather than using DWARF constructs directly, it would emit magic field
names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR".  Since
PR #45225, though, even this has not worked -- the ad hoc scheme was
not updated to handle the wider variety of niche-filling layout
optimizations now available.

This patch changes the generated DWARF to use the standard tags meant
for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part.

The patch to implement this went in to LLVM 7.  In order to work with
older versions of LLVM, and because LLVM doesn't do anything here for
PDB, the existing code is kept as a fallback mode.

Support for this DWARF is in the Rust lldb and in gdb 8.2.

Closes #32920
Closes #32924
Closes #52762
Closes #53153
@bors

This comment has been minimized.

Contributor

bors commented Oct 31, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: tromey
Pushing 0db7abe to master...

@bors bors merged commit 98b2688 into rust-lang:master Oct 31, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@michaelwoerister

This comment has been minimized.

Contributor

michaelwoerister commented Oct 31, 2018

🎉 🎉 🎉 !

@tromey tromey deleted the tromey:enum-debuginfo branch Oct 31, 2018

tromey added a commit to tromey/rust that referenced this pull request Nov 5, 2018

Fix emission of niche-filling discriminant values
Bug rust-lang#55606 points out a regression introduced by rust-lang#54004; namely that
an assertion can erroneously fire when a niche-filling discriminant
value is emitted.

This fixes the bug by removing the assertion, and furthermore by
arranging for the discriminant value to be masked according to the
size of the niche.  This makes handling the discriminant a bit simpler
for debuggers.

The test case is from Jonathan Turner.

Closes rust-lang#55606

tromey added a commit to tromey/rust that referenced this pull request Nov 7, 2018

Disable some pretty-printers when gdb is rust-enabled
A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after rust-lang#54004, the pretty-printers
can't handle enums at all).  This patch disables these pretty-printers
when gdb is rust-enabled.

The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.

bors added a commit that referenced this pull request Nov 12, 2018

Auto merge of #55701 - tromey:ice-fix, r=matthewjasper
Fix emission of niche-filling discriminant values

Bug #55606 points out a regression introduced by #54004; namely that
an assertion can erroneously fire when a niche-filling discriminant
value is emitted.

This fixes the bug by removing the assertion, and furthermore by
arranging for the discriminant value to be masked according to the
size of the niche.  This makes handling the discriminant a bit simpler
for debuggers.

The test case is from Jonathan Turner.

Closes #55606

kennytm added a commit to kennytm/rust that referenced this pull request Nov 14, 2018

Rollup merge of rust-lang#55767 - tromey:disable-some-pretty-printers…
…, r=nikomatsakis

Disable some pretty-printers when gdb is rust-enabled

A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after rust-lang#54004, the pretty-printers
can't handle enums at all).  This patch disables these pretty-printers
when gdb is rust-enabled.

The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.

kennytm added a commit to kennytm/rust that referenced this pull request Nov 14, 2018

Rollup merge of rust-lang#55767 - tromey:disable-some-pretty-printers…
…, r=nikomatsakis

Disable some pretty-printers when gdb is rust-enabled

A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after rust-lang#54004, the pretty-printers
can't handle enums at all).  This patch disables these pretty-printers
when gdb is rust-enabled.

The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.

tromey added a commit to tromey/rust that referenced this pull request Nov 15, 2018

Disable some pretty-printers when gdb is rust-enabled
A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after rust-lang#54004, the pretty-printers
can't handle enums at all).  This patch disables these pretty-printers
when gdb is rust-enabled.

The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.

kennytm added a commit to kennytm/rust that referenced this pull request Nov 17, 2018

Rollup merge of rust-lang#55767 - tromey:disable-some-pretty-printers…
…, r=nikomatsakis

Disable some pretty-printers when gdb is rust-enabled

A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after rust-lang#54004, the pretty-printers
can't handle enums at all).  This patch disables these pretty-printers
when gdb is rust-enabled.

The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment