Bug 88116

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