Unwinding support

[Amanieu]

This is actually required to ensure safety. Currently the following safe code causes a segfault: https://gist.github.com/Amanieu/9f4854c096fa519f046ace876779be60

Based on top of #51

[dpc]

What's the plan with this in the light of panic aborting by default?

[Amanieu]

This PR is now complete. I implemented unwinding support on all supported architectures, and even threw in ARM support as well.

[spinda]

Why hasn't this been merged?

[whitequark]

@spinda Currently this breaks bare-metal usage, which is the reason to use libfringe.

[dpc]

What was the problem on bare-metal? From what I understand, seems like a clever solution. I really wish this was implemented already.

[edef1c]

@dpc We don't have a workable unwinder for bare metal. I've gotten started writing one, but I'm short on time.
I miight see if we can set this up as a Cargo feature.

[whitequark]

@edef1c What? Of course we do, libunwind supports bare metal properly and I use it with libfringe.

The problem is that std doesn't export enough hooks into the panic machinery, so we end up with a pretty nasty case where we reimplement half of std::panicking.

[dpc]

Did you brought it up to rust devs? Any chance it work eventually?

[whitequark]

Did you brought it up to rust devs?

No. Personally I'm quite overloaded on OSS right now.

Any chance it work eventually?

There's no inherent technical reason it can't work.

[dpc]

Please someone knowledgeable enough open an issue with Rust devs and explain it briefly if that's what is blocking it. :)

[edef1c]

@whitequark oh, huh. I thought that was the issue we had with unwinding on bare metal.

[Amanieu]

I rebased my PR and made unwinding an optional feature.

[edef1c]

@Amanieu can you open a new PR for that? I can't reopen because GitHub is dumb about rebasing while a PR is closed