powerpc64le SIGILL

[tgross35]

Just making a note of this for my future reference: it seems like the musl implementations have crashes on PPC LE. I don't know if this is because of a bug in musl or qemu, but based on the below it seems like just a qemu thing.

Qemu execution:

$ LD_LIBRARY_PATH='/target/powerpc64le-unknown-linux-gnu/de
bug/build/musl-math-sys-1082aab9c9d13406/out:/target/powerpc64le-unknown-linux-gnu/debug/deps:/target/powerpc64le-unknown-linux-gnu/debug:/root/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/lib:/root/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib' OUT_DIR=/target/powerpc64le-unknown-linux-gnu/debug/build/libm-test-625573e9becfdb68/out qemu-ppc64le-static -g 1234 /target/powerpc64le-unknown-linux-gnu/debug/deps/compare_to_musl-cf318f8dd1aeaaa8 --exact tan

GDB session

$ gdb-multiarch
(gdb) target remote :1234
Remote debugging using :1234
Reading /target/powerpc64le-unknown-linux-gnu/debug/deps/compare_to_musl-cf318f8dd1aeaaa8 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /target/powerpc64le-unknown-linux-gnu/debug/deps/compare_to_musl-cf318f8dd1aeaaa8 from remote target...
...
(No debugging symbols found in target:/lib64/ld64.so.2)
Failed to read a valid object file image from memory.
0x0000100000837a80 in ?? () from target:/lib64/ld64.so.2
(gdb) set arch powerpc:common64
The target architecture is set to "powerpc:common64".
(gdb) set endian little
The target is set to little endian.
(gdb) c
Continuing.
Reading /lib/libc.so.6 from remote target...
Reading /lib/libm.so.6 from remote target...
Reading /lib/libgcc_s.so.1 from remote target...
Error while mapping shared library sections:
`target:/lib/libgcc_s.so.1': not in executable format: file format not recognized
Reading /usr/lib/debug/.build-id/9b/d190627d3463a2d2cf11d9250fb5619e7711ca.debug from remote target...
...
[New Thread 8887.8899]

Thread 2 received signal SIGILL, Illegal instruction.
[Switching to Thread 8887.8899]
0x000000010013c03c in musl___tan (x=0.24606256779289892, y=y@entry=0, odd=odd@entry=0) at /checkout/musl/src/math/__tan.c:92
92              v = z*(T[2] + w*(T[4] + w*(T[6] + w*(T[8] + w*(T[10] + w*T[12])))));
(gdb) bt
#0  0x000000010013c03c in musl___tan (x=0.24606256779289892, y=y@entry=0, odd=odd@entry=0) at /checkout/musl/src/math/__tan.c:92
#1  0x0000000100148cc4 in musl_tan (x=<optimized out>) at /checkout/musl/src/math/tan.c:60
#2  0x00000001000ccb2c in musl_math_sys::tan (a=0.24606256779289892) at crates/musl-math-sys/src/lib.rs:18
#3  0x00000001000cdd90 in libm_test::{impl#43}::call (self=..., f=0x1000ccb10 <musl_math_sys::tan>) at crates/libm-test/src/lib.rs:161
#4  0x0000000100042320 in compare_to_musl::tan () at crates/libm-test/tests/compare_to_musl.rs:180
#5  0x0000000100023ab0 in compare_to_musl::tan::{closure#0} () at crates/libm-test/tests/compare_to_musl.rs:164
#6  0x000000010004ba8c in core::ops::function::FnOnce::call_once<compare_to_musl::tan::{closure_env#0}, ()> () at /rustc/55a22d2a63334e0faff0202b72a31ce832b56125/library/core/src/ops/function.rs:250
...
(gdb) info args
x = 0.24606256779289892
y = 0
odd = 0

Looks like the instruction is lxsd

   0x10013c030 <musl___tan+112>:        addis   r9,r2,-7                                                                                                                                                             
   0x10013c034 <musl___tan+116>:        lfd     f0,18504(r9)                                                                                                                                                         
   0x10013c038 <musl___tan+120>:        addis   r9,r2,-7
=> 0x10013c03c <musl___tan+124>:        lxsd    v12,18512(r9)                                                                                                                                                       
   0x10013c040 <musl___tan+128>:        addis   r9,r2,-7                                                                                                                                                             
   0x10013c044 <musl___tan+132>:        fmul    f9,f8,f8

[tgross35]

The same platform was having failures with catch_unwind in #351