Skip to content

Addition of debug info to official builds #36452

Closed
@larsbergstrom

Description

@larsbergstrom
Contributor

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

Activity

luser

luser commented on Sep 13, 2016

@luser
Contributor

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

luser commented on Sep 13, 2016

@luser
Contributor

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

retep998 commented on Sep 14, 2016

@retep998
Member

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

larsbergstrom commented on Oct 7, 2016

@larsbergstrom
ContributorAuthor

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

vvuk

vvuk commented on Oct 13, 2016

@vvuk
Contributor

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

luser commented on Oct 18, 2016

@luser
Contributor

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

retep998 commented on Oct 18, 2016

@retep998
Member

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

cuviper commented on Oct 18, 2016

@cuviper
Member

@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

brson commented on Oct 18, 2016

@brson
Contributor

@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

brson commented on Oct 18, 2016

@brson
Contributor
cuviper

cuviper commented on Oct 18, 2016

@cuviper
Member

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

retep998 commented on Oct 18, 2016

@retep998
Member

@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

brson commented on Oct 18, 2016

@brson
Contributor

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

alexcrichton commented on Oct 18, 2016

@alexcrichton
Member

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

brson commented on Oct 18, 2016

@brson
Contributor

@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

alexcrichton commented on Oct 19, 2016

@alexcrichton
Member

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

luser commented on Oct 19, 2016

@luser
Contributor

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.

added a commit that references this issue on Oct 21, 2016

Auto merge of #37280 - alexcrichton:debuginfo, r=brson

e470827
vvuk

vvuk commented on Oct 21, 2016

@vvuk
Contributor

#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 want test::run_tests_console::07b8e...).

alexcrichton

alexcrichton commented on Oct 21, 2016

@alexcrichton
Member

@vvuk were you using this nightly?

rustc 1.14.0-nightly (f09420685 2016-10-20)

If so that doesn't include e470827, the merge commit with #37280

vvuk

vvuk commented on Oct 22, 2016

@vvuk
Contributor

Indeed! Okay, will check with the next one and report again.

added a commit that references this issue on Jan 11, 2017

Auto merge of #38984 - alexcrichton:less-debuginfo, r=brson

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @cuviper@alexcrichton@brson@vvuk@luser

        Issue actions

          Addition of debug info to official builds · Issue #36452 · rust-lang/rust