Use gimli instead of libbacktrace by default

[alexcrichton]

This issue is intended to track the switch from the C library libbacktrace by default on many platforms to using Gimli by default on these platforms to symbolicate a backtrace. The rationale for this is that the C library libbacktrace has had a number of security issues historically and we're including it in every single Rust binary by default on relevant platforms (in libstd), so correctness is quite important to us.

Platforms that use libbacktrace by default are:

• MinGW Windows.
• macOS (when built in libstd, in the crate coresymbolication is on by default).
• Linux / other cfg(unix) targets.

The usage of libbacktrace is relatively simple. We're either consulting the debuginfo, if available, what the symbol name for an address is or we're consulting the dynamic symbol table (aka dladdr on Unix, but I don't think this is exactly how libbacktrace gets its).

There's one caveat in our usage of libbacktrace in that we have to manually feed in a filename for the current executable to libbacktrace for macOS/Windows platforms. For other Unix platforms I think it finds it through the dynamic library iteration APIs in libc.

Another final caveat is that to fully replace libbacktrace all of the support we use for gimli must be #![no_std]. That way it can be included into the standard library, and the standard library can't depend on itself!

Today the gimli-symbolize feature of this crate actually doesn't depend on gimli at all but rather goes through external crates like addr2line, findshlibs, and memmap. I suspect that we'll probably need to drop the dependencies on findshlibs and memmap in favor of manually calling the libc APIs here, but if we can work around that it would be great! Note, though, that we don't need full featured platform support in these crates.

I think the best thing to do is to probably read up on how libbacktrace acquires debug information to parse. I think it's quite different for Windows/Mac/Linux but I suspect it's relatively straightforward and shouldn't really require that much of libstd/crates.io.

[fitzgen]

Note that moria (a crate to find an artifact's DWARF debug info) is more functional than it was at the time I contributed the gimli-symbolize backend. The reason that gimli-symbolize is currently linux only is because the DWARF bits necessary for symbolication are generally not stripped on linux, and we didn't have a good way to find external DWARF otherwise.

Today the gimli-symbolize feature of this crate actually doesn't depend on gimli at all but rather goes through external crates like addr2line, findshlibs, and memmap

addr2line has #![no_std] support right now.

findshlibs should be relatively easy to add #![no_std] support to, I think. I'm curious why you think dropping that dep and using the raw APIs is better here.

Regarding memmap, it's probably simpler to fs::read the file into memory.

[fitzgen]

cc @philipc

[alexcrichton]

I'm curious why you think dropping that dep and using the raw APIs is better here.

Oh sorry to be clear I think it's worse ergonomics and usability-wise to use raw APIs, but I was hoping to head off pain of crates trying to be #![no_std] when there' not really any use case other than "this may be included in libstd". It may just not make sense for a crate like findshlibs to have support for #![no_std], and the support needed by this crate may be small enough that it's just easier to roll by hand in the long run.

For memmap, it's true yeah that fs::read may be better, but we don't even have access to that :(

[luser]

Note that moria (a crate to find an artifact's DWARF debug info) is more functional than it was at the time I contributed the gimli-symbolize backend

I think I've mentioned this elsewhere but moria is probably not a good candidate for no-std since it relies on finding debug files on the filesystem. I guess you could make it work if you abstracted away the bits it actually needs from libstd like Path and File and let std instantiate it with its internal implementations?

[luser]

I guess this crate already has an implementation of roughly the same thing moria does anyway, but it'd need similar work to be no-std friendly:

backtrace-rs/src/symbolize/gimli.rs

Line 295 in b5cc5b1

// The loading path for OSX is is so different we just have a completely