Panicking doesn't work on arm-unknown-linux-musleabi

[vojtechkral]

Noticed a regression when running tests with a latest nightly on our xilinx arm machine. This seems to be caused by 5941acd - with Rust 1.38 stable toolchain, panicking works as expected.

With current nightly, when I build a simple program that just panics, I get:

thread 'main' panicked at 'Hello, world!', src/main.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
fatal runtime error: failed to initiate panic, error 9
Aborted

With libunwind debug env vars turned on, I get:

thread 'main' panicked at 'Hello, world!', src/main.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
libunwind: _Unwind_RaiseException(ex_obj=0x53110)
libunwind: __unw_init_local(cursor=0xbec68360, context=0xbec67e28)
libunwind: __unw_get_proc_info(cursor=0xbec68360, &info=0xbec67e00)
libunwind: __unw_get_proc_name(cursor=0xbec68360, &buf=0xbec688fc, bufLen=512)
libunwind: __unw_get_reg(cursor=0xbec68360, regNum=-1, &value=0xbec67dfc)
libunwind: unwind_phase1(ex_ojb=0x53110): pc=0x29a20, start_ip=0x299cc, func=.anonymous., lsda=0x0, personality=0x29f9c
libunwind: unwind_phase1(ex_ojb=0x53110): calling personality function 0x29f9c
libunwind: __unw_get_proc_info(cursor=0xbec68360, &info=0xbec67d7c)
libunwind: _Unwind_GetLanguageSpecificData(context=0xbec68360) => 0x0
libunwind: __unw_step(cursor=0xbec68360)
libunwind: __unw_get_reg(cursor=0xbec68360, regNum=13, &value=0xbec67d68)
libunwind: _Unwind_VRS_Get(context=0xbec68360, regclass=0, reg=13, rep=0, value=0xBEC67DD0, result = 0)
libunwind: _Unwind_VRS_Set(context=0xbec68360, regclass=0, reg=13, rep=0, value=0xBEC67DB0)
libunwind: __unw_set_reg(cursor=0xbec68360, regNum=13, value=0xbec67db0)
libunwind: __unw_get_reg(cursor=0xbec68360, regNum=11, &value=0xbec67d68)
libunwind: _Unwind_VRS_Get(context=0xbec68360, regclass=0, reg=11, rep=0, value=0xBEC68B24, result = 0)
libunwind: _Unwind_VRS_Set(context=0xbec68360, regclass=0, reg=13, rep=0, value=0xBEC68B24)
libunwind: __unw_set_reg(cursor=0xbec68360, regNum=13, value=0xbec68b24)
libunwind: unwind_phase1(ex_ojb=0x53110): personality result 9 start_ip 299cc ehtp 0x406c4 additional 1
fatal runtime error: failed to initiate panic, error 9
Aborted

Some of the addresses above:

• 0x29a20 is inside _Unwind_RaiseException
• 0x299cc is (the start of) _Unwind_RaiseException
• 0x29f9c is __aeabi_unwind_cpp_pr0

[vojtechkral]

I wonder if this might be related: https://reviews.llvm.org/D68972 (revision in SVN). I'll try to test.

It wasn't related.

[vojtechkral]

I think I probably know what the problem is. The method getByte() in file Unwind-EHABI.cpp in llvm-project/libwuwind is differentiated based on macro __LITTLE_ENDIAN__. I suspect this macro is for some reason not set when (cross)compiling the toolchain. This makes the unwinding instruction interpretation function _Unwind_VRS_Interpret get the instructions in the wrong order (and also off by one).

Edit: Yes, that was the problem. With __LITTLE_ENDIAN__ defined, panicking works again even on nightly. I'll create a PR...

[pnkfelix]

triage: P-high. Has PR. assigning to @vojtechkral

[vojtechkral]

I wonder what other platforms - if any - were affected. I was meaning to test on a Raspberry Pi with gnu libc, but ended up not having the time to do it...

[vojtechkral]

It would be cool if a fix for this (PR #65972) could be backport-nominated. Do you think it's eligible @pnkfelix @alexcrichton ?

[alexcrichton]

Seems reasonable to me! Although we're in the middle of a release right now so it's going to end up on beta in a few days anyway and I don't think we'll rebuild the stable release to include that.

[vojtechkral]

@alexcrichton Ok, thanks

[stefson]

@vojtechkral do you still need some testing on other targets than arm-unknown-linux-musleabi? I can offer armv7a-unknown-linux-musleabihf (v1.38.0 and v1.39.0)

[vojtechkral]

@stefson Sure, if you want, you can test which toolchains work (in terms of panicking) on that platform :)

[stefson]

Ok, please give me instructions on what to exactly go for.

[vojtechkral]

@stefson It should be enough to build & run a simple program that panics, such as:

fn main() {
    panic!("Hello, World!");
}

If the toolchain's panicking support is broken, it may segfault or it may print an error message after the panic message is printed.