Bug 530165 - valgrind does not understand 'address-size-override loopne'
Summary: valgrind does not understand 'address-size-override loopne'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: valgrind
Version: 5.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Dodji Seketeli
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On: 522330
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-21 18:38 UTC by Jeff Bastian
Modified: 2018-10-20 04:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 08:03:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
loopnel.s demo program (946 bytes, text/plain)
2009-10-21 18:38 UTC, Jeff Bastian
no flags Details
loopneq.s demo program (946 bytes, text/plain)
2009-10-21 19:03 UTC, Jeff Bastian
no flags Details


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 211371 0 None None None Never
Red Hat Product Errata RHEA-2010:0272 0 normal SHIPPED_LIVE valgrind bug fix and enhancement update 2010-03-29 13:20:27 UTC

Description Jeff Bastian 2009-10-21 18:38:24 UTC
Created attachment 365575 [details]
loopnel.s demo program

Description of problem:
valgrind does not handle address-size-override prefix with loopne instruction.  valgrind gives an error if it encounters this instruction:
   vex amd64->IR: unhandled instruction bytes: 0x67 0xE0 0xFA 0xB8 0x2A 0x6

According to the source code, valgrind does not support the address-size-override prefix; from valgrind-3.2.1/VEX/priv/guest-amd64/toIR.c

   case 0xE0: /* LOOPNE disp8: decrement count, jump if count != 0 && ZF==0 */
   case 0xE1: /* LOOPE  disp8: decrement count, jump if count != 0 && ZF==1 */
   case 0xE2: /* LOOP   disp8: decrement count, jump if count != 0 */
    { /* The docs say this uses rCX as a count depending on the
         address size override, not the operand one.  Since we don't
         handle address size overrides, I guess that means RCX. */
      ...
      if (have66orF2orF3(pfx) || haveASO(pfx)) goto decode_failure;

The haveASO() function checks for the address-size-override prefix (0x67).

Please add support for the address-size-override prefix.


Version-Release number of selected component (if applicable):
valgrind-3.2.1-6.el5.x86_64

How reproducible:
every time

Steps to Reproduce:
1. install RHEL 5.4 on x86_64 system
2. gcc -g loopnel.s
3. valgrind ./a.out
  
Actual results:
vex amd64->IR: unhandled instruction bytes: 0x67 0xE0 0xFA 0xB8 0x2A 0x6

Expected results:
valgrind handles the instruction

Additional info:

Comment 1 Jeff Bastian 2009-10-21 18:43:56 UTC
Disassembly of the loop:

  4004ed:       b9 03 00 00 00          mov    $0x3,%ecx
  4004f2:       83 c3 01                add    $0x1,%ebx
  4004f5:       67 e0 fa                loopnel 4004f2 <main+0x2e>
  4004f8:       b8 2a 06 40 00          mov    $0x40062a,%eax

Comment 2 Jeff Bastian 2009-10-21 19:03:11 UTC
Created attachment 365579 [details]
loopneq.s demo program

Note: using 64-bit registers on x86_64 keeps valgrind happy:

$ diff loopnel.s loopneq.s
32c32
<       movl    $3, %ecx
---
>       movq    $3, %rcx
35c35
<       loopnel .L3
---
>       loopneq .L3

$ gcc -g loopneq.s

$ valgrind -q ./a.out
start count = 0
end count = 3

Comment 3 Jakub Jelinek 2009-10-21 19:13:26 UTC
I'll add it, but in the testcase it makes absolutely no sense, just bigger code.
movl $NNN, %ecx already zero-extends the value to 64-bits, so it is cheaper to just use loopne (== loopneq in 64-bit code).

Comment 4 Jeff Bastian 2009-10-21 19:22:51 UTC
I also reported this upstream:
  https://bugs.kde.org/show_bug.cgi?id=211371

Comment 7 Jakub Jelinek 2009-10-26 08:26:46 UTC
The support is added in rawhide valgrind (valgrind-3.5.0-amd64-loopnel.patch).

Comment 25 errata-xmlrpc 2010-03-30 08:03:50 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0272.html


Note You need to log in before you can comment on or make changes to this bug.