Bug 133984 - (int 3) vex x86->IR: unhandled instruction bytes: 0xCC 0x89 0xEC 0x31
Summary: (int 3) vex x86->IR: unhandled instruction bytes: 0xCC 0x89 0xEC 0x31
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks: 256630
  Show dependency treegraph
 
Reported: 2006-09-12 21:53 UTC by Peter Maydell
Modified: 2011-08-10 15:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
patch to valgrind 3.2.0 to support int3 (1.52 KB, patch)
2006-09-13 00:18 UTC, Peter Maydell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Maydell 2006-09-12 21:53:19 UTC
Version:           valgrind-3.2.0-Debian (backports.org compile) (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

valgrind doesn't recognise the 'int 3' (0xCC) instruction. Watch:

zircon$ cat /tmp/int3.c
int main(void)
{
   asm volatile("int $3");
   return 0;
}
zircon$ #!gcc
#gcc -g -Wall -O2 -o /tmp/int3 /tmp/int3.c
zircon$ gcc -g -Wall -O2 -o /tmp/int3 /tmp/int3.c
zircon$ cat /tmp/int3.c
int main(void)
{
   asm volatile("int $3");
   return 0;
}
zircon$ gcc -g -Wall -O2 -o /tmp/int3 /tmp/int3.c
zircon$ /tmp/int3
Trace/breakpoint trap (core dumped)
zircon$ valgrind /tmp/int3
==32639== Memcheck, a memory error detector.
==32639== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==32639== Using LibVEX rev 1606, a library for dynamic binary translation.
==32639== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==32639== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework.
==32639== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==32639== For more details, rerun with: -v
==32639== 
vex x86->IR: unhandled instruction bytes: 0xCC 0x89 0xEC 0x31
==32639== valgrind: Unrecognised instruction at address 0x8048369.
==32639== Your program just tried to execute an instruction that Valgrind
==32639== did not recognise.  There are two possible reasons for this.
==32639== 1. Your program has a bug and erroneously jumped to a non-code
==32639==    location.  If you are running Memcheck and you just saw a
==32639==    warning about a bad jump, it's probably your program's fault.
==32639== 2. The instruction is legitimate but Valgrind doesn't handle it,
==32639==    i.e. it's Valgrind's fault.  If you think this is the case or
==32639==    you are not sure, please let us know and we'll try to fix it.
==32639== Either way, Valgrind will now raise a SIGILL signal which will
==32639== probably kill your program.
==32639== 
==32639== Process terminating with default action of signal 4 (SIGILL): dumping core
==32639==  Illegal opcode at address 0x8048369
==32639==    at 0x8048369: main (int3.c:3)
==32639== 
==32639== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==32639== malloc/free: in use at exit: 0 bytes in 0 blocks.
==32639== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==32639== For counts of detected errors, rerun with: -v
==32639== All heap blocks were freed -- no leaks are possible.
Illegal instruction

When run standalone the program generates a SIGTRAP. Under valgrind you get the message about
an unrecognised instruction followed by a SIGILL.

I know 'int 3' (the breakpoint trap) isn't exactly the most common instruction to find in a program, but the program I'm trying to run under valgrind does allow it (it's a JIT VM system and we catch SIGTRAP and mess with the sigcontext so we can kill just the VM process which did the bp rather than the whole system dying). Besides, it ought to be implemented for completeness :-)
Comment 1 Peter Maydell 2006-09-13 00:18:46 UTC
Created attachment 17746 [details]
patch to valgrind 3.2.0 to support int3

I had a play about with the valgrind sources, and the attached patch is the
result. It seems to work for me, and it's based on what the powerpc support
does with trap instructions, but it ought to be checked by somebody who
understands the internals of VEX. (In particular, is Dis_StopHere the right
thing, and is the state of the virtual CPU definitely properly synchronised
before we take the signal?)
Comment 2 Tom Hughes 2011-08-10 15:12:11 UTC
This has been supported since VEX r1736 (on x86) and VEX r1741 (on amd64).