sepcomp-lib-lto test fails on master with --enable-debug
#26447
Labels
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
A-testsuite
Area: The testsuite used to check the correctness of rustc
Comments
steveklabnik
added
the
A-testsuite
|
I’ve hit this in both exactly this test and compiling a regular program (i.e. not a test) via |
jdm
added
the
A-debuginfo
bors
added a commit
that referenced
this issue
Jul 21, 2015
fix `configure`: allow both `--enable-debug` and `--disable-debuginfo` in one invocation. This is my very local fix to allow one to be able to (1.) build `rustc` and (2.) run `make check` with internal debug-mode *assertions* turned on in the presence of bugs like #26447 and #26484 (both of which are solely caused by debuginfo and thus can be sidestepped via `--disable-debuginfo`). This partially addresses #24416 (namely, it addresses the papercut outlined in the description of that ticket). But there are other issues mentioned in the comment thread that are not addressed here, so they should be separately addressed before closing that ticket, or separate bugs should be opened for them.
|
This is caused by debuginfo generic enums. If you have e.g.: fn main() {
let x = Some(0);
}debuginfo will be generated for the type |
dotdash
added a commit
to dotdash/rust
that referenced
this issue
Aug 12, 2015
When using a generic enum type that was defined in an external crate, our debuginfo currently claims that the concrete type (e.g. Option<i32>) was defined in the current crate, where it was first used. This means that if there are multiple crates that all use, for example, Option<i32> values, they'll have conflicting debuginfo, each crate claiming to have defined that type. This doesn't cause problems in regular builds, but with LTO enabled, LLVM complains because it tries to merge the debuginfo for those types and sees the ODR violations. Since I couldn't find a way to get the file info for the external crate that actually defined the enum, I'm working around the issue by using "<unknown>" as the file for enum types. We'll want to re-visit and fix this later, but this at least this fixes the ICE. And with the file being unknown instead of wrong, the debuginfo isn't really worse than before either. Fixes rust-lang#26447
bors
added a commit
that referenced
this issue
Aug 16, 2015
When using a generic enum type that was defined in an external crate, our debuginfo currently claims that the concrete type (e.g. Option<i32>) was defined in the current crate, where it was first used. This means that if there are multiple crates that all use, for example, Option<i32> values, they'll have conflicting debuginfo, each crate claiming to have defined that type. This doesn't cause problems in regular builds, but with LTO enabled, LLVM complains because it tries to merge the debuginfo for those types and sees the ODR violations. Since I couldn't find a way to get the file info for the external crate that actually defined the enum, I'm working around the issue by using "<unknown>" as the file for enum types. We'll want to re-visit and fix this later, but this at least this fixes the ICE. And with the file being unknown instead of wrong, the debuginfo isn't really worse than before either. Fixes #26447
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When compiling with --enable-debug, the
sepcomp-lib-ltotest fails. It passes if I build without --enable-debug. Relevant build output:Backtrace:
The text was updated successfully, but these errors were encountered: