gimli-symbolize fails with compressed debug info

[benesch]

I've put together a full reproduction, with commentary, here: https://github.com/benesch/rust-zdebuginfo

The gist is that Rust generates an absolutely massive amount of debug info by default. (For a deep dive into why, see MaterializeInc/materialize#2691.) One easy workaround is to compress the debug info sections, which you can accomplish on Linux with a .cargo/config like the following:

rustflags = ["-C", "link-arg=-Wl,--compress-debug-sections=zlib-gabi"]

Unfortunately, with the new gimli-symbolizer feature, backtraces produced by such a binary fail to symbolicate, though the libbacktrace-based implementation handles them fine.

[alexcrichton]

Thanks for the report! I learned today that libbacktrace embedded a zlib inflater. That's something I never knew before, and is quite surprising to me!

In any case given that this is supported by libbacktrace this definitely seems worthwhile to support with gimli too.

[benesch]

I learned today that libbacktrace embedded a zlib inflater. That's something I never knew before, and is quite surprising to me!

libbacktrace is a pretty wild piece of software, isn't it? :) It's amazing how much software you have to vendor to get reliable backtraces across the various platforms/compiler toolchains that it supports.

I'm happy to take a stab at this, @alexcrichton. Let me pop over to gimli and have a look around—unless you're already working on this?

[alexcrichton]

Nah feel free!

I'll warn you though that this crate is semi-nonstandard in that I've been trying to keep the dependencies super slim for eventual inclusion of gimli into libstd. In that sense the implementation may duplicate a bit what's already in the object crate or be a bit verbose, but that's ok! In general I'd recommend getting something working and then we can always work to slim it down later. Fixing crates.io seems like a good primary goal in the meantime.

[benesch]

I'll warn you though that this crate is semi-nonstandard in that I've been trying to keep the dependencies super slim for eventual inclusion of gimli into libstd.

Heh, that was actually what motivated me to file this issue! It's easy enough for us to opt-into the old implementation at Materialize when using the library from crates.io, but we'll be in trouble if this winds up in libstd, where we can't twiddle the knobs.

In general I'd recommend getting something working and then we can always work to slim it down later.

👍 thanks for the heads up!