i686-musl + catch_unwind = fatal runtime error: failed to initiate panic, error 5

[japaric]

STR

use std::panic;

fn main() {
    let _ = panic::catch_unwind(|| panic!());
}

$ RUST_BACKTRACE=1 cargo run --target i686-unknown-linux-musl
    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/i686-unknown-linux-musl/debug/foo`
thread 'main' panicked at 'explicit panic', src/main.rs:4
stack backtrace:
fatal runtime error: failed to initiate panic, error 5
error: Process didn't exit successfully: `target/i686-unknown-linux-musl/debug/foo` (signal: 6, SIGABRT: process abort signal)

Meta

$ rustc -V
rustc 1.12.0-nightly (0ef24eed2 2016-08-10)

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04 LTS
Release:        16.04
Codename:       xenial

cc @alexcrichton

[alexcrichton]

cc @vadimcn, maybe related to the changes in the personality?

[vadimcn]

Sure it's possible :)
@japaric: Can I assume that this worked before? Say, on nightly-2016-06-22?

[japaric]

Not sure, I haven't really used catch_unwind with this target before, but the snippet also fails with beta (rustc 1.11.0-beta.3 (052e32bd9 2016-08-08)) and with an older nightly (rustc 1.11.0-nightly (6dcc2c1de 2016-06-22)).

[alexcrichton]

Oh if it never worked then I wonder if libunwind that we're using is just busted?

[vadimcn]

I would place my bet on unwind tables not being registered properly. How hard is it to set up a musl build?

[alexcrichton]

For me it was just:

$ rustup target add i686-unknown-linux-musl
$ rustc foo.rs --target i686-unknown-linux-musl
$ ./foo

[vadimcn]

Okay, I've managed to repro this.
Looks like only i686-unknown-linux-musl is broken, x86_64-unknown-linux-musl works fine.

[alexcrichton]

Ok got a chance to dig a bit more into this. Some things I've learned:

• We compile LLVM's libunwind for musl
• We do so with the host g++ binary. So technically we're compiling against glibc and then linking it with musl. We do this for x86_64 and it works, though, so while this is a problem I'm not sure that it's causing this problem.
• The unwinder is finding all unwind data (using dl_iterate_phdr on Linux).
• The unwinder successfully unwinds one frame
• One frame aftewards the instruction pointer goes off into the weeds
• At this point the unwinder gives up because it can't unwind.

So basically it looks like everything is working except the literal unwind step is either reading bad or wrong values. I haven't been able to get much further yet.

[alexcrichton]

Found the problem!

The LLVM port of libunwind has historically understood that the dwarf register numbers for ebp and esp were 4 and 5, respectively. Recent changes, however (llvm-mirror/libunwind@85e3961 and llvm-mirror/libunwind@99e90f4) have noticed that there's some conflating of values going on here. More info in https://reviews.llvm.org/D22508 as well, but the tl;dr; is these values need to be swapped and then everything works.

[alexcrichton]

More links:

http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20140811/012309.html
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20140811/012324.html