Ability to choose libunwind backend

Currently, the C library behind the libunwind crate is chosen based on some heuristics of the target (https://github.com/rust-lang/rust/blob/master/src/libunwind/build.rs). However, the choice is sometimes not optimal.

In my case, I'm trying to cross-compile for a musl-based dynamically linked target. This chooses statically liked libunwind for me, which is not what I want. First, I try to save on the binary size, so I'd like to avoid adding another dependency (while gcc_s is already present on the system). I actually don't care about unwinding (I compile with panic=abort) and I'd be willing to forgo backtrace support as well. However, the more important reason is, I get a lot of unresolved references during the final linking (it may be related to mismatch between dynamic and static linking, or my compilation of libunwind does different mangling of the names, or something).

Currently I patch the libunwind sources, so gcc_s is chosen instead, and that works. But I'd prefer some more systematic way. Would it be possible to add some kind of configuration knob (something like there's force_alloc_system for std) to override the heuristics, to either gcc_s or some kind of dummy implementation that produces empty backtraces and supports only panic=abort? What would be the right process to do that? Should I just try submitting a pull request, or should I write an RFC first?

I'm aware this would be an option available only when compiling my own std (like through xargo), but I still think there's a class of devices which are powerful enough to want to use std, but where saving space is still important.

Start by reading src/libunwind/build.rs and the existing force_alloc_system configuration pattern mentioned in the issue. Review the RFC process to determine whether selectable gcc_s or dummy libunwind backends need an RFC. Done means reaching an agreed design and process for overriding the backend heuristics, including the panic=abort use case.