Closed
Description
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.
Activity
luser commentedon Sep 13, 2016
There are two related issues here:
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 commentedon Sep 13, 2016
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 commentedon Sep 14, 2016
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 commentedon Oct 7, 2016
cc @vvuk, re: the thread in #servo on name mangling and MSVC.
vvuk commentedon Oct 13, 2016
So I think to do this, we need:
pdb
files get copied alongpdb
files directly, or put them in a separate-debuginfo
component forrustup
If someone can give me a pointer on where to look for each of these three things, I can create PRs for this.
luser commentedon Oct 18, 2016
We discussed this on IRC, but I think all we actually need is:
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 commentedon Oct 18, 2016
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 debuggingrustc
itself. For applications that statically linklibstd
, just enabling debuginfo inconfig.toml
is sufficient.cuviper commentedon Oct 18, 2016
@retep998 Do you mean enabling debuginfo in your own
Config.toml
? That only helps for generic or inline-able code fromlibstd
. Anything that was actually compiled to object code in therlib
won't have debuginfo that way. (At least for ELF+DWARF -- I'm not sure how Windows pdbs work withrlib
.)brson commentedon Oct 18, 2016
@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 commentedon Oct 18, 2016
Here's the line to change in configure
cuviper commentedon Oct 18, 2016
The Linux way is usually a separate step afterward, something like
strip -g -o foo.debug foo
retep998 commentedon Oct 18, 2016
@cuviper I mean the
config.toml
that rustbuild reads settings from, which is the modern way to build rustc that doesn't involveconfigure
ormake
.brson commentedon Oct 18, 2016
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 commentedon Oct 18, 2016
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 commentedon Oct 18, 2016
@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.
4 remaining items
alexcrichton commentedon Oct 19, 2016
I've sent a PR to enable at least line number information in releases, so we can evaluate the impact from that and see if it works for Gecko.
luser commentedon Oct 19, 2016
If that at least gets us function names and source line info that should be sufficient for crash reporting purposes. We'll likely eventually want full debug info for developers doing actual debugging, but maybe we can figure out something smarter before then.
Auto merge of #37280 - alexcrichton:debuginfo, r=brson
vvuk commentedon Oct 21, 2016
#37280 isn't sufficient for Windows -- with an Oct 20 nightly build, source information is missing from any standard rust libs. Additionally, for Windows, we need more than just line numbers unfortunately. rustc always uses gnu-style mangling, so we need debug info for the symbols to make sense in the debugger (you get
_ZN4test17run_tests_console17h07b8e649031d5e08E
when you wanttest::run_tests_console::07b8e...
).alexcrichton commentedon Oct 21, 2016
@vvuk were you using this nightly?
If so that doesn't include e470827, the merge commit with #37280
vvuk commentedon Oct 22, 2016
Indeed! Okay, will check with the next one and report again.
rustbuild: Don't enable debuginfo in rustc
Auto merge of #38984 - alexcrichton:less-debuginfo, r=brson
rustbuild: Don't enable debuginfo in rustc