can't compile libstd with -Z debug-info #9167

Closed
glycerine opened this Issue Sep 13, 2013 · 11 comments

Projects

None yet

7 participants

@glycerine

version:

  • master fd39bd1 auto merge of #9148 : jakub-/rust/rustpkg-install-mkdir-p, r=catamorphism

libextra and libsyntax seem to build okay with -Z debug-info, but libstd complains:

MATCHES=""; if [ -n "$MATCHES" ] ; then echo "Warning: removing previous" \'libstd-*.so\' "libraries:" $MATCHES; rm $MATCHES ; fi
x86_64-unknown-linux-gnu/stage2/bin/rustc --cfg stage2   --cfg debug -Z no-debug-borrows -Z debug-info  --target=x86_64-unknown-linux-\
gnu  -D warnings --out-dir x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib /usr/cn/rust/debug-build/rust/src/libstd/std.rs && touch x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd.so
/usr/cn/rust/debug-build/rust/src/libstd/unstable/intrinsics.rs:402:8: 402:38 warning: debuginfo: Could not find namespace node for function. This is a bug! Try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
/usr/cn/rust/debug-build/rust/src/libstd/unstable/intrinsics.rs:402     pub fn get_tydesc<T>() -> *TyDesc;
                                                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/cn/rust/debug-build/rust/src/libstd/unstable/intrinsics.rs:430:8: 430:57 warning: debuginfo: Could not find namespace node for function. This is a bug! Try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
/usr/cn/rust/debug-build/rust/src/libstd/unstable/intrinsics.rs:430     pub fn visit_tydesc(td: *TyDesc, tv: &mut TyVisitor);
                                                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/cn/rust/debug-build/rust/src/libstd/unstable/intrinsics.rs:398:8: 398:37 warning: debuginfo: Could not find namespace node for function. This is a bug! Try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
/usr/cn/rust/debug-build/rust/src/libstd/unstable/intrinsics.rs:398     pub fn min_align_of<T>() -> uint;

... (lots and lots of similar errors... pointing to intrinsics.rs:398     pub fn min_align_of<T>() -> uint;  not shown)

@glycerine

possibly related to
#7603

@jdm
Contributor
jdm commented Sep 13, 2013

Heads up @michaelwoerister.

@enomado
enomado commented Sep 14, 2013

even better

While deleting: metadata %
An asserting value handle still pointed to this value!
UNREACHABLE executed at /home/sc/projects/rust/rust/src/llvm/lib/IR/Value.cpp:632!
[1]    12427 abort (core dumped)  rustc -Z debug-info src/libstd/std.rs
rustc -Z debug-info src/libstd/std.rs  31.66s user 2.74s system 95% cpu 35.938 total
@bors bors added a commit that referenced this issue Oct 8, 2013
@bors bors auto merge of #9658 : michaelwoerister/rust/namespace_fixes, r=jdm
This should fix some outstanding namespace issues. It also fixes an issue with LLVM metadata uniquing that caused an LLVM assertion when compiling libstd.

One thing to keep in mind is that the `-O` flag and the debug info flags are essentially incompatible. It may work but I would not consider this in any way supported at the moment. On the other hand, there is also good news: With the changes in this PR I am able to compile all of rust with extra-debug-info:
```
make RUSTFLAGS_STAGE2='-Zextra-debug-info' check
```
compiles the whole thing without warning and passes the whole test suite (given that `configure` is run with `--disable-optimize`). That's kind of nice `:)` Still, I'm reluctant to automatically close the related issues (#9167, #9190, #9268) without confirmation from the openers. I'll post to the individual threads once this gets merged.
e87205c
@michaelwoerister
Contributor

As of #9658 being merged into master, the errors described here (both by @glycerine and @enomado) do not occur anymore (tested on 32 and 64 bit Linux, with -Zdebug-info, no -O flag).
Anyone care to test on other systems? Otherwise I think this issue can be closed.

@thestinger thestinger closed this Oct 8, 2013
@huonw
Member
huonw commented Oct 8, 2013

@michaelwoerister does this mean we can compile the stdlib & compiler with -Z debug-info now?

@glycerine

sweet. @huonw, yes, according to #9658

@michaelwoerister
Contributor

@huonw Yes, that should work now, albeit only with optimizations turned off.

@pnkfelix
Member
pnkfelix commented Oct 8, 2013

-Z debug-info -Z extra-debug-info does not seem to work for me (on Mac OS X with 6db8899 ). Will check about -Z debug-info

https://gist.github.com/pnkfelix/6892686

(never mind though, those are failures from passing these flags to the stage0 rustc...)

@pnkfelix
Member
pnkfelix commented Oct 8, 2013

Nonetheless, we still should explicitly track the problems that arise when you have optimizations turned on.

There are two classes of potential problems: Issues where the debug-info does not properly reflect the program state (a common problem in any programming language when mixing optimizations and debug-info), and Issues where the compiler actually fails to compile a program correctly (ignoring the output debug-info). If we are getting LLVM assertion failures, then we are effectively seeing the latter, since the assertion failure will cause a debug-build of LLVM to die.

@pnkfelix
Member
pnkfelix commented Oct 9, 2013

From some initial experiments, I can confirm that one can bootstrap a non-optimized rustc build with -Z extra-debug-info, and that attempting to bootstrap an optimized rustc build with -Z extra-debug-info does indeed hit assertion failures.

It would be good for us to address the assertion failures, but I'll probably first take the step I outlined in #9770 of extending the configure script with a flag to turn this stuff on for the libraries built during rustc bootstrapping.

@michaelwoerister
Contributor

(never mind though, those are failures from passing these flags to the stage0 rustc...)

Yes, that's a bit tricky until we have a new snapshot. I always used RUSTFLAGS_STAGE2=... to work around this.

There are two classes of potential problems...

Yes, it's definitely the second kind of failure. And as far as I can tell from my (rather preliminary) investigation of the problem, it happens before any optimization passes even run. That is, if my mental model of rustc's workflow is right:

  1. (parse, type check, etc)
  2. trans (generate complete LLVM IR for the crate)
  3. feed completed LLVM IR into LLVM which
    1. does optimization transformations on the IR
    2. compiles the (possibly optimized) IR to machine code

If it really works that way then we are just using LLVM's DIBuilder in some unsupported way. That this only occurs in optimized builds should actually make it easier to track the problem down.
If the above workflow is more interleaved --- that is, during IR generation LLVM's builder already does something based on the fact that optimizations are activated --- then it's probably more complicated to find the culprit.

Adding debug info options to the configure script can't hurt, I guess. I'd definitely use them :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment