Compiling crates with debugging symbols

[artella-coding]

It would be nice to be able to compile crates (such as "rand") with debugging symbols.

For example if I have :

extern crate rand;
use rand::{task_rng, Rng};

fn main() {
    let names = ["Alice", "Bob", "Carol"];
    for name in names.iter() {
        let v = task_rng().shuffle(~[1,2,3]);
        for num in v.iter() {
            println!("{:s} says: {:d}", *name, *num);
        }
    }
}

Then I can put a breakpoint at shuffle by doing :

rustc -g prog1.rs
gdb ./prog1
rbreak shuffle
run

However I cannot step into shuffle and nagivate the code of shuffle. See https://mail.mozilla.org/pipermail/rust-dev/2014-April/009495.html for more details. Thanks.

[huonw]

You can compile the core libraries with debug symbols yourself using make RUSTFLAGS='-g', however, I'm not 100% sure that the bootstrap succeeds with debug-info (historically, this is why the --enable-debug flag does not enable debugging symbols: the support wasn't good enough).

If it does work, and @michaelwoerister thinks that we're ready, then maybe we could enable -g when configured with --enable-debug.

(On that note: it would probably be a good idea for us to be able to just enable debugging for the non-compiler libs, since debug info isn't free, and the compiler libraries are already rather large and slow to compile.)

[michaelwoerister]

Currently, using make RUSTFLAGS='-g' does not work because of #13213. The issue has been fixed but I think the current snapshot does not yet contain the fix.

But the RUSTFLAGS solution does not leave much control really and can certainly be improved on. One important constraint to take into account here is that debuginfo doesn't work very well for optimized code. At the same time we may not want to have an unoptimized version of rustc (which really is rather slow) just because we need a debug version of librand. So this should definitely be controllable separately. However, this is where the bootstrapping setup might cause some trouble, since rustc relies on the same libraries that are later linked into user code. I suspect that an unoptimized libstd could considerably slow down an optimized version of rustc. So for people that don't need debug symbols for the compiler itself, there would have to be two versions of libstd and the extra libraries:

• an optimized version for use with an optimized rustc
• an unoptimized version for linking into debug builds

People working on the compiler might want to have an unoptimized version of rustc with debuginfo which would then also have to be linked to unoptimized libraries. Note that all of this is still a separate issue from debug logging that is enabled when configuring with --enable-debug. Also, one might conceivably also want an optimized build with debuginfo (which can still be useful) and an unoptimized build without debuginfo (for space reasons).

In conclusion, this is all a bit more complicated than it might seem at first sight. One way to support all possible scenarios would be to always create all combinations of optimization * debuginfo for std and extra and then somehow let the users decide what they want to link against. But that would increase compilation time and space requirements quit a bit. I would at least want to be able to opt out of that; rustc already takes long enough to compile.

I'll have to think about this a little more. Any comments are very welcome of course!

[steveklabnik]

Given that #13213 has been merged, I'm giving this a close. Improvements are always welcome though!