CODEWITHSUNDEEP
c++macosgccx86valgrind
Ryan
Ryan

Reputation: 1501

valgrind unhandled instruction bytes: 0xF 0xB 0xFF 0x85

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...

Upvotes: 1

Views: 3498

Answers (2)

Matthew Slattery
Matthew Slattery

Reputation: 47038

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.

Upvotes: 3

Bob Fincheimer
Bob Fincheimer

Reputation: 18066

I have no idea if this helps, but that looks to be an undefined instruction:

http://ref.x86asm.net/coder32.html#x0F0B

More like: http://ref.x86asm.net/coder32.html#xFB

Looks to be some low level interrupt management going on (for semaphores for example). But usually this can only be done by privileged threads in kernel mode, so I wonder why that code can do it.

More likely I am incorrect about which instruction, but it would make sense that valgrind doesn't know much about the interrupt instruction in x86

Upvotes: 0

Related Questions