#![no_std] support

[est31]

It seems that this library is needed when we want to include addr2line into libstd (rust-lang/rust#46439). In order for this to be possible, we require #![no_std] support though.

[est31]

I've had a look at the code and most of the stuff seems to be portable, except for the usage of CStr. But as CStr is just a wrapper around C pointers, we can just expose &[c_uchar] instead, or something like that.

[mitsuhiko]

I found the return value of CStr quite annoying to deal with even in std use. I was considering to propose to change it to OsStr but that is also not possible in nostd. One option I find quite appealing is to have name() return &[c_uchar] and have a high level wrapper that converts name into a Path which is what library users are likely to be interested in anyways.

[fitzgen]

@alexcrichton do you have any ideas on how to both

• support windows, which uses utf-16 for various section/segment/etc names (aka OsStr)
• support #![no_std] for inclusion in libstd (no OsStr)

I guess we could have multiple name methods on Segment and SharedLibrary that return the name as a OsStr or raw bytes, and then we can cfg their presence on/off based on what we are targeting...

See also #36

[alexcrichton]

I honestly haven't really thought through what would be necessary to move backtrace-the-crate to gimli by default, which currently requires this being #![no_std] and such. I think that taking exactly what's there today and #![no_std]-ifying it is probably not the way to go. Something like this crate I don't think really makes sense in a #![no_std] world since backtrace would probably be the only users and that's exclusively because it's built into libstd.

I've written up some thoughts about gimil-by-default in the backtrace crate at rust-lang/backtrace-rs#189. That'll probably change a lot over time though!

[mitsuhiko]

I would generally like to restructure the crate a tad because some of the things here don't necessarily make too much sense at this point. I think it might be useful to see what data backtrace needs from here and then figure out a no-std version specifically for backtrace and nothing more.

[philipc]

backtrace is using addr2line without needing this.

[est31]

Yeah the issue isn't important any more due to the findshlibs dependency having been removed from the backtrace crate: rust-lang/backtrace-rs#314