'Illegal instruction' for any operation on Linux

[kalligator]

./kalker-linux
kalker
Type 'help' for instructions.
>> 1+1
Illegal instruction

>> 1+1=
Unable to parse expression.

OS: Elementary 6.0b (based on Ubuntu 20.04)

[PaddiM8]

This is super odd. Seems to only happen to some Linux users. Someone with a very very similar setup to mine had this problem, while I didn't. Most likely a problem with the gmp-mpfr-sys crate, so I'm not quite sure what to do about it. Hmm. I wonder if it works when done through cargo install kalker

[kalligator]

I'm now posting from Elementary OS 5.17 (Ubuntu 18.04 base).
I tried running the binary but it was complaining about /lib/x86_64-linux-gnu/libm.so.6: version 'GLIBC_2.29' not found
So tried the cargo install and it works fine.
Will get back about eOS 6b & cargo install.

[kalligator]

OK I installed it with no complaints in eOS6b.
I tried running kalker from terminal -> command not found. I thought it wasn't auto added to the path.
I went into the ~/.cargo/bin dir to run it directly from there -> command not found again. oops sorry my bad, I did not perpend './' before trying to run it. So ./kalker from inside the dir does work.
I added it to Path and it now works normally from anywhere.

[PaddiM8]

Ah I see thanks. The gmp-mpfr-sys Rust crate (library) seems to not support cross-compilation to different platforms, so maybe it also struggles when it's the same platform but different machines... Hm... Will look into it.

[livkaye]

If you're able to run the broken kalker binary in Valgrind (valgrind ./kalker), Valgrind should generate a core dump which contains more information about the instruction it couldn't handle. Top of it should look something like this.

vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0xFB 0xF6 0x18 0x48 0x85 0xDB 0x78 0x18
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==4324== valgrind: Unrecognised instruction at address 0x14bb10.

This particular example was caused by a mulx instruction, which is part of the BMI2 instruction set. If you run lscpu and don't find bmi2 in the CPUID flags, the release published here won't work. This particular instruction is used for multiplications and divisions (mpfr_mul, mpfr_div).

All operations result in entering the function mpfr_frac as part of estimating the result in terms of pi or e. In the published release this function includes the instruction lzcnt, which is part of the ABM instruction set. The CPUID flag for this is abm. I hijacked a friend's evening to run some silly little commands for me and on his machine this was raised as a SIGABRT rather than a SIGILL for some reason, and Valgrind's core dump started with ../../mpfr-src/src/frac.c:80: GNU MP assertion failed: sh < (64 - 0).

The same friend also sent me a binary they built on their machine which worked, didn't have the mulx instruction. If you can somehow get MPFR to build using -mtune=generic and -march=x86-64 that might help.