Red Hat Bugzilla – Bug 530165
valgrind does not understand 'address-size-override loopne'
Last modified: 2018-10-20 00:05:13 EDT
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:
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
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
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).
I also reported this upstream: https://bugs.kde.org/show_bug.cgi?id=211371
The support is added in rawhide valgrind (valgrind-3.5.0-amd64-loopnel.patch).
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