integration into libstd

[est31]

Hi, has integration into libstd been attempted yet (rust-lang/rust#46439)? Have there been any blockers that are not resolved yet? If no, I'd like to conduct such a project.

Blockers for addr2line itself (in no particular order):

• port gimli to #![no_std] (no_std support gimli#138)
• gimli release with #![no_std] support (New release for #![no_std] support gimli#303)
• make gimli use stable_deref_trait 1.1.0 and use it without it depending on std (Disable default features of stable_deref_trait gimli#306 )
• gimli release that includes the modified entry for stable_deref_trait (0.16.1)
• StableDeref impls for #![no_std] types in stable_deref_trait (Add StableDeref impls for no_std types, including alloc and spin types Storyyeller/stable_deref_trait#2)
• update addr2line to gimli 0.16.0 ( Update to gimli 0.16.0  #91)
• update addr2line to object 0.9.0 (Update object to 0.9.0 #93)
• port cpp_demangle to #![no_std] (Use fmt machinery instead of io one cpp_demangle#146 , Add a #![no_std] port cpp_demangle#148)
• cpp_demangle release with #![no_std] support (0.2.10)
• add #![no_std] to lazycell (Add #![no_std] indiv0/lazycell#85)
• lazycell release with #![no_std] (Cut the 0.6.0 release indiv0/lazycell#86)
• port addr2line from lazy-init to lazycell (Switch to lazycell #94)
• port addr2line to #![no_std] (#![no_std] support #90, Implement no_std support #102)
• addr2line release with #![no_std] support (here)

[fitzgen]

This crate is for symbolicating addresses, which is only half the story. The other half is walkign the stack to get the addresses for symbolication. There is a WIP crate for that here, but it needs lots of love to get into a place where it could go into rustc, I suspect.

That said, I would also love to see that happen. It is "just" a matter of doing the (substantial amount of) work :)

[main--]

My work on unwind-rs has pretty much stalled for now as I got tied up in other projects. It works fine on x86_64 but that's about it. For me to continue on this there would need to be some serious interest from the rustc side as well as another contributor, I don't have the time (nor the hardware) to do it all alone.

AFAIK addr2line is quite solid at this point and using that for symbolication instead of libbacktrace in rustc should work in principle (naturally, I would expect the bigger exposure to discover a few bugs).

[est31]

According to this comment, libbacktrace isn't used for walking the stack, so addr2line integration alone would allow us to remove libbacktrace.

[philipc]

Yep, my understanding is that libunwind is used for walking the stack, both for backtraces and unwinding after panics, and libbacktrace is used for symbolication. addr2line is suitable for symbolication, such as in backtrace-rs.

I think one of the blockers was getting no_std support, based on this comment. That has been done in the object crate, but addr2line still needs updating (I have done some work on this but it's currently blocked on a new gimli release).

For addr2line to be usable on OSX, we also need to hook up something like https://github.com/gimli-rs/moria to find the DWARF, but that can probably be done externally to addr2line. There's also the possible need to get it from object files (#87). Both of these can come after getting linux support working though.

[est31]

I think one of the blockers was getting no_std support

Thanks, I've filed a bug for a new gimli release as well as no_std support and added them to the newly created blocker list above.

For addr2line to be usable on OSX

To my knowledge, right now we don't support backtraces on OSX anyway. So an initial version can ship without MacOS support just fine.

[fitzgen]

To my knowledge, right now we don't support backtraces on OSX anyway. So an initial version can ship without MacOS support just fine.

rustc (via libunwind) will very much walk/unwind the stack on osx. The symbolication strategy they use just doesn't get file/line/column, but they do get symbolicate addresses into demangled symbols.

[luser]

For addr2line to be usable on OSX, we also need to hook up something like https://github.com/gimli-rs/moria to find the DWARF, but that can probably be done externally to addr2line.

This sounds right. FWIW, moria is trying to be a general-purpose crate, but for Rust standard library purposes you could probably get away with something simple like:
https://github.com/gimli-rs/moria/blob/b38bbf1f165f9dc874b9ea69a277c4857b61d7cd/src/lib.rs#L194

You'd just need to get the UUID from the LC_UUID load command in the Mach-O headers, but that's not hard.

[est31]

The release has since happened so all items on the list I have made last year are checked. However I'm not closing this issue, as instead of my PR rust-lang/rust#51440 , acrichto's PR rust-lang/rust#56092 got merged. My PR only required #![no_std] support, but now, special code in Cargo.toml is needed as well. This needs to be done on all of addr2line's recursive dependencies. See a detailed list here. If anyone wants to revive my PR, I'm happy to help.

[philipc]

I think this will be fixed by #166