Remove smallvec dependency

[alexcrichton]

This commit removes smallvec as a dependency of the read feature of
this crate. This is an extension of #494 to help make gimli easier to
include into the standard library. The smallvec crate was only used in
one location inside of gimli, in Abbreviation parsing. This was
converted to a manual inline small-vector along with a new type
Attributes to wrap this up. This also removes smallvec from the
public API of gimli to allow future changes to the representation if
necessary.

[philipc]

No objection to what these PRs are doing, and I'll try to review them tomorrow.

This one needs a fix for 32-bit builds though, and that beta SIGSEGV is a concern, but probably not due to this PR?

[alexcrichton]

Sure thing, and no rush of course! I'll take a look at the errors here.

[alexcrichton]

Bah ok I fixed the 32-bit issue but the SIGSEGV went away there. I wasn't able to reproduce locally (not even with valgrind or address sanitizer!).

[philipc]

The point of using SmallVec is for performance, so here's some numbers for bench_parsing_debug_abbrev:

SmallVec:      9,989 ns/iter (+/- 468)
Attributes:   13,101 ns/iter (+/- 810)
Vec:          16,621 ns/iter (+/- 521)

So it's still an improvement over Vec at least, and maybe we can tune it more later. I think we should keep it private though.

[philipc]

Thanks! Needs another rebase.

[alexcrichton]

Rebased! Sorry meant to comment that earlier.

FWIW I don't want to make it seem like these dependency removals must happen to get the backtrace crate working. I think it's best for libstd inclusion to have as few deps as possible, but zero is not the goal. If you feel that any of these dependency removals causes too much burden or overhead in the gimli crate, it's totally fine to take a different solution.

The primary purpose of this crate is a high-quality dwarf reader/writer, not meeting the weird requirements of libstd! It may be the case that addr2line doesn't need the pieces I'm removing these dependencies from so there may be alternatives or something like that to keep the deps but get the rough goal of "the backtrace crate works ideally with almost no deps".

Basically I want to reiterate that I don't want to place an undue maintenance burden on the gimli crates. The use case of backtrace is a bit weird unfortunately :(

[philipc]

The extra testing that will result from gimli being used in libstd will help improve improve its quality, so I think it's worth it.

addr2line doesn't need the CFI support, which is where the unsafe code was added, so we potentially could make CFI a feature instead if it becomes unmanageable, but I think it's ok for now at least. Are there any plans to do unwinding using gimli too? Probably too far away to be worth worrying about now.

[alexcrichton]

Unwinding with libunwind has been reliable enough for now that I don't think there's any immediate need to switch to gimli for unwinding. It at least has been far more reliable than libbacktrace has been!

I'd be totally down for a feature of the backtrace crate to use gimli for unwinding though to start to prove it out, but that's much further down the road I think.