Addition of debug info to official builds

[larsbergstrom]

Currently, it's hard to debug some Rust code in Firefox because the standard library does not have symbol information included. That means that all of the code that gets inlined from the stdlib has no source location info. It would be great to generate official builds with symbol info and package that in the official builds.

cc @alexcrichton @froydnj @luser

[luser]

There are two related issues here:

1. This makes our crash reports worse, since many frames in a crash report from libstd will be missing function names / source line info. (The exception here is generics.)
2. This makes the debugging story worse. I was trying to debug an issue with Rust panics in Firefox on Win64 and it got incomprehensible very quickly, especially since we build with lto, so your simple Rust function winds up with a ton of inlined bits of libstd.

Neither of these are huge issues yet, since we don't have much Rust code. As we pull things like Stylo in, they're going to quickly become a problem.

Rust is in a unique situation here compared to C or C++. With those languages you typically dynamically link the standard library, so you can always get debug symbols for the one you're using after-the-fact. Since Rust always statically links in libstd if you don't have debug symbols at build time you are out of luck.

[luser]

Related, Rust omits frame pointers by default, so not having debug symbols in libstd likely means not getting good backtraces through libstd in a debugger. (I suspect this works OK on Linux because rustc does emit .eh_frame sections for the object files in libstd, even on x86.)

[retep998]

This would really improve the debugging experience on Windows, in particular with msvc. If a function was generated with debuginfo, then VS's debugger is able to display the unmangled name, and can even do step by step debugging through the source code if it is available. When stepping into a function from libstd, all it sees is an opaque mangled symbol which makes it hard to tell what is going on.

[larsbergstrom]

cc @vvuk, re: the thread in #servo on name mangling and MSVC.

[vvuk]

So I think to do this, we need:

• build with debuginfo=true in a config.toml for a rustbuild
• when installing the various bits into the stage2/ dest dir, make sure the pdb files get copied along
• when packaging, either package the pdb files directly, or put them in a separate -debuginfo component for rustup

If someone can give me a pointer on where to look for each of these three things, I can create PRs for this.

[luser]

We discussed this on IRC, but I think all we actually need is:

• build with debuginfo=true in a config.toml for a rustbuild

Since the bits of lib{core,std} that people will actually be linking against are rlibs, which should have the debug info embedded in the object files contained within.

[retep998]

Copying along and packaging pdb files is useful for debugging when you're linking against the dylib crates (which only plugins should ever do), or for debugging rustc itself. For applications that statically link libstd, just enabling debuginfo in config.toml is sufficient.

[cuviper]

@retep998 Do you mean enabling debuginfo in your own Config.toml? That only helps for generic or inline-able code from libstd. Anything that was actually compiled to object code in the rlib won't have debuginfo that way. (At least for ELF+DWARF -- I'm not sure how Windows pdbs work with rlib.)

[brson]

@vvuk It looks to me like we could just pass --enable-debuginfo to the configure script on the release builders and that would work fine (or we could just turn that option on by default), though I'm not sure what that will do with pdb files (I suspect they will be packaged along with the libs if they are generated correctly).

If we could persuade rustc to emit elf debuginfo in a separate file then I'd definitely be in favor of making a separate debuginfo package. I don't know if LLVM/rustc can generate such files though.

It's probably worth making the simple change to the configure script and seeing how it affects both total tarball size and build times. If it's a big drag on build times then we might not want to turn it on by default when in the "dev" channel.

[brson]

Here's the line to change in configure

[cuviper]

If we could persuade rustc to emit debuginfo in a separate file

The Linux way is usually a separate step afterward, something like strip -g -o foo.debug foo

[retep998]

@cuviper I mean the config.toml that rustbuild reads settings from, which is the modern way to build rustc that doesn't involve configure or make.

[brson]

FWIW I don't think we can get away from configure+make as an interface to the build system. It's a standard that unixes expect.

[alexcrichton]

I believe @brson is correct here where we just need to pass --enable-debuginfo on the MSVC nightly builders. Unfortunately rustbuild (e.g. the Cargo.toml files) do not generate the MSVC distribution right now, so changing them wouldn't actually fix the problem here.

@brson I think we may prefer though to change buildbot config rather than our build script here, right?

I'd also prefer to only do this for MSVC right now as it'd be more of a PITA to run strip or other tools for Unixes.

[brson]

@alexcrichton why only for windows? I'd prefer to keep feature parity between platforms.

The reason to change configure is that others packaging rust would get debuginfo as well. If that's the experience we want our users to have then doing it by default helps distros get it right.

Why would we need to run strip on the unixes? I was assuming we would just include the debuginfo inside the binaries for now, to get the feature out. If someday somebody teaches rustc to put the debuginfo beside the bins then we can turn that on.