illegal instruction

[lgottwald]

I managed to compile this using your instructions and additionally modifying the configure script to accept the kernel version and gcc version of ubuntu 16.04. But then when I tested it on the example I got the following error.

==26562== FpDebug-0.1, Floating-point arithmetic debugger
==26562== Copyright (C) 2010-2011 by Florian Benz.
==26562== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==26562== Command: fpdebug/examples/test_1.out
==26562==
==26562== precision=120
==26562== mean-error=yes
==26562== ignore-libraries=no
==26562== ignore-accurate=yes
==26562== sim-original=no
==26562== analyze-all=yes
==26562== bad-cancellations=yes
==26562== ignore-end=no
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1B 0x84 0x24 0x80 0x0 0x0
==26562== valgrind: Unrecognised instruction at address 0x4017cee.
==26562== at 0x4017CEE: _dl_runtime_resolve_sse (dl-trampoline.h:93)
==26562== Your program just tried to execute an instruction that Valgrind
==26562== did not recognise. There are two possible reasons for this.
==26562== 1. Your program has a bug and erroneously jumped to a non-code
==26562== location. If you are running Memcheck and you just saw a
==26562== warning about a bad jump, it's probably your program's fault.
==26562== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26562== i.e. it's Valgrind's fault. If you think this is the case or
==26562== you are not sure, please let us know and we'll try to fix it.
==26562== Either way, Valgrind will now raise a SIGILL signal which will
==26562== probably kill your program.
==26562==
==26562== Process terminating with default action of signal 4 (SIGILL)
==26562== Illegal opcode at address 0x4017CEE
==26562== at 0x4017CEE: _dl_runtime_resolve_sse (dl-trampoline.h:93)
==26562==
==26562== SHADOW VALUES (fpdebug/examples/test_1.out_shadow_values_relative_error_5): successful
==26562== SHADOW VALUES (fpdebug/examples/test_1.out_shadow_values_canceled_5): successful
==26562== SHADOW VALUES (fpdebug/examples/test_1.out_shadow_values_special_5): successful
==26562== MEAN ERRORS (fpdebug/examples/test_1.out_mean_errors_addr_5): successful
==26562== MEAN ERRORS (fpdebug/examples/test_1.out_mean_errors_canceled_5): successful
==26562== MEAN ERRORS (fpdebug/examples/test_1.out_mean_errors_intro_5): successful
==26562== DEBUG - Client exited with code: 0
--26562-- DEBUG - SBs: 1,362, executed: 16,153, instr: 48,945
--26562-- DEBUG - ShadowValues (frees/mallocs): 0/0, diff: 0
--26562-- DEBUG - Floating-point operations: 0
--26562-- DEBUG - Max temps: 201
--26562-- OPTIMIZATION - GET: total 3,358, ignored: 196
--26562-- OPTIMIZATION - STORE: total 1,372, ignored: 0
--26562-- OPTIMIZATION - PUT: total 12,159, ignored: 3,774
--26562-- OPTIMIZATION - LOAD: total 1,922, ignored: 0
Illegal instruction

[fbenz]

Point 3.3 in Valgrind's FAQ http://valgrind.org/docs/manual/faq.html mentions two possibilities:

1. a bug in the analyzed program
2. an instruction that is unknown to Valgrind

As the examples are quite simple and have worked before, I'm pretty sure that there is an actual instruction that Valgrind 3.7 does not know yet. This is also quite likely as Valgrind is 3.7 is a few years old by now and a recent compiler targeting a recent CPU might use instructions that have been introduced in the meantime. I see two options to solve this:

1. Compile the example targeting an older CPU.
2. Upgrade FpDebug to a newer Valgrind version.

Option 1 is of course way simpler than option 2.

[lgottwald]

We tried option 1 by using the -march=x86-64 flag for gcc when compiling the example, so gcc should not have generated instructions that only work for recent processors. Or do you think a different option for the march flag must be used?

[fbenz]

My guess is that it fails on new SSE instructions and therefore I suggest trying out -march=core2. With core2 GCC is only using instructions up to SSE3, see https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options

[lgottwald]

I now tried this option too, although -march=x86-64 should only use SSE2 so an even older instruction set, Unfortunately it did not work, and I think it might be due to the old valgrind version.
During the configure I had to change the configure script to accept the 4.4 kernel of the ubuntu 16.04 and the gcc version so that it accepts 5.*, so probably something is not compatible anymore and the only fix seems to be option 2.
Do you think this is a feasible amount of work?

[fbenz]

Migrating to Valgrind 3.12 is definitely some work. I started with the first step of making the code compile: https://github.com/fbenz/FpDebug/tree/valgrind_3.12
There is definitely more migration work to be done, e.g.:

• Investigate what happened with the removed instructions. I just commented them out for now.
• Likely a few new instructions have to be supported.

Afterwards one has to test that everything is still working as intended. Testing and checking for unsupported instructions is a good way of lazily adding required instructions.

I can not promise any timeline and would of course be happy for contributions in that direction.

[fbenz]

FpDebug is now able to compile and run with Valgrind 3.12. The small examples are running as expected on my machine (Ubuntu 16.10). In addition, I provided bash scripts to simplify the installation process. Calling the following scripts is sufficient to compile everything:

./install_gmp.sh
./install_mpfr.sh
./install_valgrind.sh

See #2

[fbenz]

Closing because it is fixed by #2. If there are still unhandled cases in the version based on Valgrind 3.12 a new issue can be created.