Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to gimli-symbolize by default #324

Merged
merged 1 commit into from
May 12, 2020
Merged

Switch to gimli-symbolize by default #324

merged 1 commit into from
May 12, 2020

Conversation

alexcrichton
Copy link
Member

This commit switches this crate to using gimli by default for parsing
DWARF debug information. This is a long time coming and brings a number
of benefits:

  • Primarily, Rust is safe. The libbacktrace library has been plagued
    with segfaults ever since we first started using it. Gimli, however,
    is almost entirely safe code. This should make us much more resilient
    in the face of buggy debuginfo.

  • Secondarily, it means this library no longer needs a C compiler. Being
    an all-Rust crate generally makes it much easier to cross-compile,
    port, etc.

  • Finally, this paves the road for future improvements such as
    split-debuginfo support by default. The libbacktrace library hasn't
    really changed since we started using it years ago, and this gives us
    more control over what's used and how now.

Closes #189

@alexcrichton
Copy link
Member Author

I think it's very much worth calling out @philipc for the help they did here too. The primary reason I felt like now is the time to do this is that the dependency tree of gimli-symbolize is now small enough I'm comfortable enabling it by default:

backtrace v0.3.46 (/home/alex/code/backtrace-rs)
├── addr2line v0.12.0
│   └── gimli v0.21.0
├── cfg-if v0.1.10
├── libc v0.2.69
├── object v0.19.0
└── rustc-demangle v0.1.16

@alexcrichton alexcrichton force-pushed the gimli-default branch 2 times, most recently from 682df6a to ca6cdb6 Compare May 12, 2020 17:01
This commit switches this crate to using `gimli` by default for parsing
DWARF debug information. This is a long time coming and brings a number
of benefits:

* Primarily, Rust is safe. The libbacktrace library has been plagued
  with segfaults ever since we first started using it. Gimli, however,
  is almost entirely safe code. This should make us much more resilient
  in the face of buggy debuginfo.

* Secondarily, it means this library no longer needs a C compiler. Being
  an all-Rust crate generally makes it much easier to cross-compile,
  port, etc.

* Finally, this paves the road for future improvements such as
  split-debuginfo support by default. The libbacktrace library hasn't
  really changed since we started using it years ago, and this gives us
  more control over what's used and how now.

Closes #189
@alexcrichton alexcrichton merged commit 5ad0b76 into master May 12, 2020
@alexcrichton alexcrichton deleted the gimli-default branch May 12, 2020 17:30
@nnethercote
Copy link

Is this at all related to the use of dsymutil on Mac?

@alexcrichton
Copy link
Member Author

@nnethercote I don't believe so, no, dsymutil isn't related to switching to gimli. Are you seeing some issues though?

@philipc
Copy link
Contributor

philipc commented May 12, 2020

Part of the split debuginfo support should be to allow us to avoid running dsymutil.

@nnethercote
Copy link

Recently, I briefly looked into what would be required to stop running dsymutil for rustc on Mac. It's complicated and I don't remember all the details, but backtraces on panics is a big part of the story -- dsymutil is currently needed for them to produce useful file names and line numbers.

@alexcrichton
Copy link
Member Author

@nnethercote ah yeah it is correct that avoiding dsymutil breaks backtraces. The fix for that isn't implemented yet and we just basically assumed it would not ever get fixed for libbacktrace, so we assumed it would get implemented for gimli instead.

The implementation still needs to happen and additionally this needs to be integrated into libstd, both of which are large ish chunks of work

@nikhilm
Copy link

nikhilm commented May 14, 2020

The fix for that isn't implemented yet and we just basically assumed it would not ever get fixed for libbacktrace, so we assumed it would get implemented for gimli instead.

what are the issues I should be watching for progress on non-dsymutil backtraces? Thanks!

@alexcrichton
Copy link
Member Author

#287 is probably the best choice for that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use gimli instead of libbacktrace by default
4 participants