The "enter" instruction has two forms. Valgrind supports the first, where the second arg is zero, eg: enter $8, $0 Valgrind doesn't support the second form, where the 2nd arg is non-zero, which is used to create "nested stack frames". Eg: enter $8, $1
> Valgrind doesn't support the second form, where the 2nd arg is non-zero, > which is used to create "nested stack frames". Eg: > > enter $8, $1 Urk. Does V abort on the second form, or does it silently produce a wrong translation? J
It asserts.
My valgrind 3.4.1 aborts for instruction 0xC8 0x0 0x0 0x0. Not sure if it's related to this bug The problem with 0xC8 is also reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393235 Thi is the error I get vex x86->IR: unhandled instruction bytes: 0xC8 0x0 0x0 0x0 ==3997== valgrind: Unrecognised instruction at address 0x740bfaa. ==3997== Your program just tried to execute an instruction that Valgrind ==3997== did not recognise. There are two possible reasons for this. ==3997== 1. Your program has a bug and erroneously jumped to a non-code ==3997== location. If you are running Memcheck and you just saw a ==3997== warning about a bad jump, it's probably your program's fault. ==3997== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3997== i.e. it's Valgrind's fault. If you think this is the case or ==3997== you are not sure, please let us know and we'll try to fix it. ==3997== Either way, Valgrind will now raise a SIGILL signal which will ==3997== probably kill your program. ==3997== ==3997== Process terminating with default action of signal 4 (SIGILL): dumping core ==3997== Illegal opcode at address 0x740BFAA
Actually, my valgrind doesn't support enter $0, $0 either : $ cat enter.s .global main main: enter $0, $0 leave ret $ : 1243169936:0;gcc enter.s -o enter -g $ gcc enter.s -o enter -g $ cat enter.s .global main main: enter $0, $0 leave ret $ gcc enter.s -o enter -g $ ./enter $ valgrind ./enter ==11826== Memcheck, a memory error detector. ==11826== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==11826== Using LibVEX rev 1884, a library for dynamic binary translation. ==11826== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==11826== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework. ==11826== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==11826== For more details, rerun with: -v ==11826== vex x86->IR: unhandled instruction bytes: 0xC8 0x0 0x0 0x0 ==11826== valgrind: Unrecognised instruction at address 0x8048374. ==11826== Your program just tried to execute an instruction that Valgrind ==11826== did not recognise. There are two possible reasons for this. ==11826== 1. Your program has a bug and erroneously jumped to a non-code ==11826== location. If you are running Memcheck and you just saw a ==11826== warning about a bad jump, it's probably your program's fault. ==11826== 2. The instruction is legitimate but Valgrind doesn't handle it, ==11826== i.e. it's Valgrind's fault. If you think this is the case or ==11826== you are not sure, please let us know and we'll try to fix it. ==11826== Either way, Valgrind will now raise a SIGILL signal which will ==11826== probably kill your program. ==11826== ==11826== Process terminating with default action of signal 4 (SIGILL) ==11826== Illegal opcode at address 0x8048374 ==11826== at 0x8048374: ??? (enter.s:3) ==11826== by 0x80482E0: ??? (start.S:119) ==11826== ==11826== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) ==11826== malloc/free: in use at exit: 0 bytes in 0 blocks. ==11826== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==11826== For counts of detected errors, rerun with: -v ==11826== All heap blocks were freed -- no leaks are possible. Instruction non permise $ valgrind --version valgrind-3.4.1-Debian It's a pity, since enter is indeed easy to model (if the second argument is $0, then it's equivalent to PUSH ebp; MOV ebp, esp; SUB esp, <the first argument>; I don't know the exact semantics when the second arg is != 0).
*** Bug 126240 has been marked as a duplicate of this bug. ***