rustc_codegen_llvm: support 128-bit discriminants in debuginfo.

[JohnTitor]

CC: #59509

Alternatively, if LLVM and DWARF support it, we should encode the 128-bit discriminant

If we should fix like this issue comment, I'll do.

r? @eddyb

[eddyb]

@JohnTitor We should try the alternative, but there's no guarantee it will work (I have no idea what LLVM requires internally, so it might or it might not).

[cuviper]

I think 128-bit values will still get truncated going into LLVM -- see #59509 (comment).

[JohnTitor]

Thank you @cuviper, your comments will help us! I want to hear @eddyb's thoughts.

[eddyb]

Huh, I thought everything went through a LLVM value created with const_u64.
Given what @cuviper said, we either need to improve the LLVM API or find a way to create the right metadata without its cooperation, but if it stores uint64_t internally, that has to be fixed first.

I'm readding the assert as a drive-by fix in #59519, since I had to touch that code anyway.

We should keep this PR open to document "the proper fix", or maybe even merge it now, with the assertion moved to the point where we need to pass an u64 to LLVM (so data structures on the Rust side all hold u128 losslessly).

[eddyb]

@cuviper Hang on, this PR only touches values passed through LLVMRustDIBuilderCreateVariantMemberType, which might help e.g. Option<ReprU128Enum> but not the enum itself.
This means a different assert is missing elsewhere.
I'll leave a comment on the issue itself.

We should add codegen tests, and even debuginfo (cc @nagisa@michaelwoerister).

[cuviper]

Ah, yeah, maybe they're disconnected.

[eddyb]

@cuviper Yupp, see #59509 (comment)

@JohnTitor Can you run your local rust build with --emit=llvm-ir -C debuginfo=2 on the example in the issue and look for the extraData field?
We should at least confirm LLVM doesn't do its own truncation.

[JohnTitor]

@eddyb Thank you for reviewing! I pushed commit, and changed close issue to CC: issue because this issue still has works.

---

I got this and couldn't find extraData, is my debug wrong?
Sorry, please wait(I used "not" local rust build)

EDIT: Hmm, I couldn't find extraData.(the log is here)

[eddyb]

I think we should merge this with a codegen test and debuginfo one, but debuggers might not be able to use the information, so I'm not sure.

Anyway, if you have a let vals = (Some(Foo::Lo), None::<Foo>);, the debugger should be able to show it correctly after this PR but not before.

[JohnTitor]

Okay, I want to add the tests but I don't know proper that.

[eddyb]

@JohnTitor That's why I pinged @nagisa and @michaelwoerister above, I'm not sure either.
If you want, you can poke around src/test/codegen and src/test/debuginfo, and try to add a new test based on the existing ones.

Then ./x.py test --stage 1 src/test/{codegen,debuginfo} will run the test. Since you only changed rustc_codegen_llvm, going back & forth between your changed sources and the unchanged sources should be fast, so you can make sure the new tests fail without your changes, and succeed with.

[eddyb]

Ah, wait, nowadays we have documents like this: https://rust-lang.github.io/rustc-guide/tests/adding.html

[JohnTitor]

@eddyb Uh, I added temporary tests for the moment. I don't know what good CHECK flag is.

[bors]

☔ The latest upstream changes (presumably #59590) made this pull request unmergeable. Please resolve the merge conflicts.

[rust-highfive]

The job x86_64-gnu-llvm-6.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.

travis_time:end:0003e7c6:start=1554066203239478866,finish=1554066204236886755,duration=997407889
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:02:05] extracting /checkout/obj/build/cache/2019-03-20/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
[00:02:05] error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`
[00:02:05] [00:02:05] Caused by:
[00:02:05] patch for `rustfmt-nightly` in `https://github.com/rust-lang/crates.io-index` did not resolve to any crates. If this is unexpected, you may wish to consult: https://github.com/rust-lang/cargo/issues/4678
[00:02:05] Build completed unsuccessfully in 0:00:15
[00:02:05] make: *** [prepare] Error 1
[00:02:05] Makefile:69: recipe for target 'prepare' failed
[00:02:06] Command failed. Attempt 2/5:
[00:02:06] Command failed. Attempt 2/5:
[00:02:07] error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`
[00:02:07] [00:02:07] Caused by:
[00:02:07] patch for `rustfmt-nightly` in `https://github.com/rust-lang/crates.io-index` did not resolve to any crates. If this is unexpected, you may wish to consult: https://github.com/rust-lang/cargo/issues/4678
[00:02:07] Build completed unsuccessfully in 0:00:00
[00:02:07] Makefile:69: recipe for target 'prepare' failed
[00:02:07] make: *** [prepare] Error 1
[00:02:09] Command failed. Attempt 3/5:
[00:02:09] Command failed. Attempt 3/5:
[00:02:09] error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`
[00:02:09] [00:02:09] Caused by:
[00:02:09] patch for `rustfmt-nightly` in `https://github.com/rust-lang/crates.io-index` did not resolve to any crates. If this is unexpected, you may wish to consult: https://github.com/rust-lang/cargo/issues/4678
[00:02:09] Build completed unsuccessfully in 0:00:00
[00:02:09] Makefile:69: recipe for target 'prepare' failed
[00:02:09] make: *** [prepare] Error 1
[00:02:12] Command failed. Attempt 4/5:
[00:02:12] Command failed. Attempt 4/5:
[00:02:12] error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`
[00:02:12] [00:02:12] Caused by:
[00:02:12] patch for `rustfmt-nightly` in `https://github.com/rust-lang/crates.io-index` did not resolve to any crates. If this is unexpected, you may wish to consult: https://github.com/rust-lang/cargo/issues/4678
[00:02:12] Build completed unsuccessfully in 0:00:00
[00:02:12] make: *** [prepare] Error 1
[00:02:12] Makefile:69: recipe for target 'prepare' failed
[00:02:16] Command failed. Attempt 5/5:
[00:02:16] Command failed. Attempt 5/5:
[00:02:16] error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`
[00:02:16] [00:02:16] Caused by:
[00:02:16] patch for `rustfmt-nightly` in `https://github.com/rust-lang/crates.io-index` did not resolve to any crates. If this is unexpected, you may wish to consult: https://github.com/rust-lang/cargo/issues/4678
[00:02:16] Build completed unsuccessfully in 0:00:00
[00:02:16] make: *** [prepare] Error 1
[00:02:16] Makefile:69: recipe for target 'prepare' failed
[00:02:16] The command has failed after 5 attempts.
---
travis_time:end:281973b4:start=1554066355748232927,finish=1554066355755277710,duration=7044783
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0b0c9fbc
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:06830274
travis_time:start:06830274
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:041cda52
$ dmesg | grep -i kill

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)

[rust-highfive]

The job x86_64-gnu-llvm-6.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.

travis_time:end:2294b5d0:start=1554066478057838555,finish=1554066479041370778,duration=983532223
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:25:16] Compiling rustc-demangle v0.1.10
[00:25:22] Compiling memmap v0.6.2
[00:25:22] Compiling num_cpus v1.8.0
[00:25:24] Compiling rustc_llvm v0.0.0 (/checkout/src/librustc_llvm)
[00:25:28] error[E0425]: cannot find value `niche` in this scope
[00:25:28] |
[00:25:28] |
[00:25:28] 1389 | Some(truncate(value, niche.value.size(cx)))
[00:25:28] [00:25:31] error: aborting due to previous error
[00:25:31] [00:25:31] For more information about this error, try `rustc --explain E0425`.
---
travis_time:end:11e5cbff:start=1554068021542969296,finish=1554068021547713097,duration=4743801
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:06c0b63d
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0166a57a
travis_time:start:0166a57a
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:00778f02
$ dmesg | grep -i kill

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)

[eddyb]

@bors retry

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout add-assert(switch to your branch)
2. git fetch upstream master(retrieve the latest master)
3. git rebase upstream/master -p(rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self add-assert --force-with-lease(update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging src/librustc_codegen_llvm/debuginfo/metadata.rs
CONFLICT (content): Merge conflict in src/librustc_codegen_llvm/debuginfo/metadata.rs
Automatic merge failed; fix conflicts and then commit the result.

[bors]

☔ The latest upstream changes (presumably #59897) made this pull request unmergeable. Please resolve the merge conflicts.

[rust-highfive]

The job x86_64-gnu-llvm-6.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.

travis_time:end:098f6570:start=1556962343239211108,finish=1556962344070357716,duration=831146608
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:04:17] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:17] tidy error: /checkout/src/test/debuginfo/repr-u128.rs: ignoring line length unnecessarily
[00:04:22] some tidy checks failed
[00:04:22] [00:04:22] [00:04:22] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:22] [00:04:22] [00:04:22] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:22] Build completed unsuccessfully in 0:01:11
[00:04:22] Build completed unsuccessfully in 0:01:11
[00:04:22] Makefile:67: recipe for target 'tidy' failed
[00:04:22] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:03e26570
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sat May 4 09:36:58 UTC 2019
---
travis_time:end:18891e40:start=1556962619705593361,finish=1556962619710745137,duration=5151776
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:01ed5d72
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:259c78a2
travis_time:start:259c78a2
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:17904148
$ dmesg | grep -i kill

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)

[JohnTitor]

I rebased and fixed debuginfo test.

[JohnTitor]

We no longer catch Options after rebasing, is this okay? @eddyb

[eddyb]

That doesn't make sense, what broke this?

[eddyb]

cc @michaelwoerister@alexcrichton@tmandry

[JohnTitor]

Is #59897 (comment) related?

[eddyb]

No, that's just affecting miri, and also you're not using generators at all here.

[alexcrichton]

If this is regressing something, it's likely because something changed. The only thing that really looks like it's changing is that we're always telling LLVM that there's a 128-bit discriminant. My guess is that LLVM and/or GDB isn't really prepared for that and there's some pessimization that happens somewhere. This can probably be fixed by always telling LLVM about a 64-bit discriminant when it fits and 128-bit otherwise.

Or it could be something completely different. I don't really know why I'm cc'd here and I don't really know much about this test, this PR, or debugging and descriminants being passed.

[eddyb]

This test worked before a recent rebase, according to @JohnTitor - see ea7af71 for the post-rebase diff.

However, I don't know how when or how we ever run debuginfo tests anymore, so I can't be sure of anything.

EDIT: I was wondering whether we changed anything about our LLVM recently, or anything like that. I guess I could try bisect this PR, except for the fact that debuginfo tests have been broken for me for a long while now.

[tmandry]

I checked to see if #59897 was causing this but no, I still get the <error reading variable> before that PR. Could also have been #59651 but I doubt it.

[JohnTitor]

Hmm, it seems that we need more investigation.

@eddyb How we try to bisect this PR?

[eddyb]

I'm not sure, can you squash all the changes into one commit?
That would make it easy, since you can just git cherry-pick the-hash-of-that-commit on top of any older master and build that (or even use git bisect but I never remember how to).
That's assuming this test can even be tested, that is.

[JohnTitor]

@eddyb Hmm, I'm not sure but we can catch Options again...

[JohnTitor]

ping @eddyb, what do you think? Should we do @bors try?

[bors]

😪 I'm awake I'm awake

[eddyb]

Why is GDB missing?

[JohnTitor]

@eddyb Sorry for being late. I fixed test.

[eddyb]

I'm not seeing Some or None in the tested output.

[JohnTitor]

Hmm, we cannot catch these now. This is a part of repr-u128.out.

print vals
((core::option::Option<repr_u128::Foo>, core::option::Option<repr_u128::Foo>)) $0 = (Option<repr_u128::Foo> { }, Option<repr_u128::Foo> { }) quit
None

[eddyb]

I really don't understand what's happening :/

[Centril]

r? @nagisa

[nagisa]

I was hoping to test this out locally to investigate the debuginfo test, but it fails to compile (nevermind I had extended build enabled).

Could you please squash your commits?

[nagisa]

Right, I do not think we can do this quite yet – if LLVM is built with debug assertions enabled, it aborts with following assert when building the repr-u128 test:

rustc: /sb/d/rust/src/llvm-project/llvm/include/llvm/ADT/APInt.h:1566: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed.

with following backtrace:

#0 0x00007ffff7b5fbe0 in raise () from /nix/store/db2fz1d8hka8xcyw4755ks081ljxwgac-glibc-2.27/lib/libc.so.6
#1 0x00007ffff7b60dc1 in abort () from /nix/store/db2fz1d8hka8xcyw4755ks081ljxwgac-glibc-2.27/lib/libc.so.6
#2 0x00007ffff7b586e7 in __assert_fail_base () from /nix/store/db2fz1d8hka8xcyw4755ks081ljxwgac-glibc-2.27/lib/libc.so.6
#3 0x00007ffff7b58792 in __assert_fail () from /nix/store/db2fz1d8hka8xcyw4755ks081ljxwgac-glibc-2.27/lib/libc.so.6
#4 0x00007fffe933585a in llvm::DwarfUnit::constructTypeDIE(llvm::DIE&, llvm::DICompositeType const*) ()
from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#5 0x00007fffe9335650 in llvm::DwarfUnit::constructTypeDIE(llvm::DIE&, llvm::DICompositeType const*) ()
from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#6 0x00007fffe9335b70 in llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode const*) () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#7 0x00007fffe93360d9 in llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType const*, llvm::dwarf::Attribute) ()
from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#8 0x00007fffe9337dd2 in llvm::DwarfUnit::constructMemberDIE(llvm::DIE&, llvm::DIDerivedType const*) ()
from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#9 0x00007fffe9335142 in llvm::DwarfUnit::constructTypeDIE(llvm::DIE&, llvm::DICompositeType const*) ()
from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#10 0x00007fffe9335b70 in llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode const*) () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#11 0x00007fffe93360d9 in llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType const*, llvm::dwarf::Attribute) ()
from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#12 0x00007fffe9302181 in llvm::DwarfCompileUnit::applyVariableAttributes(llvm::DbgVariable const&, llvm::DIE&) ()
from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#13 0x00007fffe931318a in llvm::DwarfDebug::finishEntityDefinitions() () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#14 0x00007fffe9322395 in llvm::DwarfDebug::finalizeModuleInfo() () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#15 0x00007fffe932a2b5 in llvm::DwarfDebug::endModule() () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#16 0x00007fffe92de963 in llvm::AsmPrinter::doFinalization(llvm::Module&) () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#17 0x00007fffea003e1b in llvm::FPPassManager::doFinalization(llvm::Module&) () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#18 0x00007fffea00e7d4 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#19 0x00007fffe86a3052 in LLVMRustWriteOutputFile () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#20 0x00007fffe85d85fc in rustc_codegen_llvm::back::write::write_output_file () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#21 0x00007fffe849f31d in rustc_codegen_llvm::back::write::codegen::{{closure}} () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#22 0x00007fffe849eabc in rustc::util::common::time_ext () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#23 0x00007fffe85db8d2 in rustc_codegen_llvm::back::write::codegen () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#24 0x00007fffe8665e1a in rustc_codegen_ssa::back::write::execute_work_item () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#25 0x00007fffe8596558 in std::sys_common::backtrace::__rust_begin_short_backtrace () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#26 0x00007fffe8548de4 in std::panicking::try::do_call () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#27 0x00007ffff7d7ddfa in __rust_maybe_catch_panic () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-093040ce4f511471.so
#28 0x00007fffe8548d47 in std::panicking::try () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#29 0x00007fffe868aa8d in core::ops::function::FnOnce::call_once{{vtable-shim}} () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#30 0x00007ffff7d6eaef in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-093040ce4f511471.so
#31 0x00007ffff7d68a90 in std::sys_common::thread::start_thread () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-093040ce4f511471.so
#32 0x00007ffff7d59bf6 in std::sys::unix::thread::Thread::new::thread_start () from /sb/d/rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-093040ce4f511471.so
#33 0x00007ffff4d5cef7 in start_thread () from /nix/store/db2fz1d8hka8xcyw4755ks081ljxwgac-glibc-2.27/lib/libpthread.so.0
#34 0x00007ffff7c1d22f in clone () from /nix/store/db2fz1d8hka8xcyw4755ks081ljxwgac-glibc-2.27/lib/libc.so.6

This would be one possible reason why the output from debuggers ends up showing no useful data, for example.

[JohnTitor]

@nagisa Okay, I squashed commits.

[nagisa]

@JohnTitor will you be investigating the assert in LLVM? It will likely be the case that the DWARF debug info generator needs to be improved to support outputting 128-bit discriminants which may or may-not need non-trivial changes upstream.

If not, then perhaps we should update the relevant issues and close the PR?

[mati865]

Doesn't look like trivial fix: https://github.com/llvm/llvm-project/blob/2946cd701067404b99c39fb29dc9c74bd7193eb3/llvm/include/llvm/ADT/APInt.h#L1565

[nagisa]

You would fix it here, but ultimately making such a change relies on DWARF format supporting that kinda of thing in the first place – which I’m not sure if it does. (yes DWARF supports arbitrarily-sized discriminants)

[JohnTitor]

It seems we should investigate more so it's reasonable to close this PR.