Question

I tried to run my program compiled with Apple GCC 3.2.1 (forced 32-bit mode, x86 only) under valgrind 3.6.1, but I get the following error during initialization phase:

vex x86->IR: unhandled instruction bytes: 0xF 0xB 0xFF 0x85
==80746== valgrind: Unrecognised instruction at address 0x2a6c2a9.
==80746== Your program just tried to execute an instruction that Valgrind
==80746== did not recognise.  There are two possible reasons for this.
==80746== 1. Your program has a bug and erroneously jumped to a non-code
==80746==    location.  If you are running Memcheck and you just saw a
==80746==    warning about a bad jump, it's probably your program's fault.
==80746== 2. The instruction is legitimate but Valgrind doesn't handle it,
==80746==    i.e. it's Valgrind's fault.  If you think this is the case or
==80746==    you are not sure, please let us know and we'll try to fix it.
==80746== Either way, Valgrind will now raise a SIGILL signal which will
==80746== probably kill your program.
==80746== 
==80746== Process terminating with default action of signal 4 (SIGILL)
==80746==  Illegal opcode at address 0x2A6C2A9

Can you please tell me what is this instruction and what should I do? If I run my application under gdb, I pass this code area without a problem…

Answer 1

The byte sequence 0xF 0xB is the opcode UD2.

This is a defined “Undefined Instruction”, if that makes any sense: there are many possible opcodes that are not legal, but this one is specifically reserved as an instruction which is guaranteed to raise a #UD invalid opcode exception, even on future processors.

There is one (and I can only think of one) vaguely plausible reason why it might be deliberately executed by code: the GCC built-in __builtin_trap() generates a UD2 instruction on x86, and I’ve occasionally seen that used instead of abort() to cause a fatal error which will be caught by a debugger.