Bug 88116 - "enter" instruction's nested variation not supported
Summary: "enter" instruction's nested variation not supported
Status: CONFIRMED
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
: 126240 (view as bug list)
Depends on:
Blocks: 256630
  Show dependency treegraph
 
Reported: 2004-08-26 11:51 UTC by Nicholas Nethercote
Modified: 2010-11-11 20:13 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Nethercote 2004-08-26 11:51:47 UTC
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
Comment 1 Julian Seward 2004-08-30 11:29:58 UTC
> 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

Comment 2 Tom Hughes 2004-08-30 11:35:08 UTC
It asserts.
Comment 3 kde4 2009-03-09 11:48:41 UTC
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
Comment 4 Matthieu Moy 2009-05-24 15:03:07 UTC
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).
Comment 5 Vince Weaver 2010-11-11 20:11:38 UTC
*** Bug 126240 has been marked as a duplicate of this bug. ***