Bug 866941

Summary: Regression vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x84 0xD2 0xF 0x95 (lock xaddb)
Product: Red Hat Enterprise Linux 6 Reporter: Mark Wielaard <mjw>
Component: valgrindAssignee: Mark Wielaard <mjw>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools-bugs
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4CC: fche, jakub, mfranc, mnewsome
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: valgrind-3.8.1-3.2.el6 Doc Type: Bug Fix
Doc Text:
Probably no documentation necessary. This was a regression in valgrind 3.8.0 which was never released before in RHEL6. The previous version in RHEL6 was based on 3.6.0. x86_64 programs using some variants of the xaddb instruction would not run under valgrind. This was a regression introduced in valgrind 3.8.0. Such programs would run normally under valgrind before. With this fix they again run under valgrind without errors.
 Story Points: ---
Clone Of: 866793
: 866943 (view as bug list) Environment:
Last Closed: 2013-02-21 08:52:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 866793    
Bug Blocks: 866943    

Description Mark Wielaard 2012-10-16 11:22:23 UTC 
+++ This bug was initially created as a clone of Bug #866793 +++

Originally https://bugzilla.redhat.com/show_bug.cgi?id=755242#c7

valgrind-3.8.1-3.fc17 fails.

[mrsam@octopus base]$ valgrind --tool=memcheck ./testhttpclientauth 
==28524== Memcheck, a memory error detector
==28524== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==28524== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==28524== Command: ./testhttpclientauth
==28524== 
vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x84 0xD2 0xF 0x95
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==28524== valgrind: Unrecognised instruction at address 0x56c947.

--- Additional comment from jakub on 2012-10-16 03:35:51 EDT ---

Weird, that is lock xaddb %dl,(%rax), that ought to be handled...

--- Additional comment from mjw on 2012-10-16 03:51:37 EDT ---

confirmed, valgrind 3.7.0 works fine, but with 3.8.x and also with upstream valgrind SVN:

$ /usr/local/install/valgrind/bin/valgrind -q --vgdb-error=0 ./test
==4405== (action at startup) vgdb me ... 
==4405== 
==4405== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==4405==   /path/to/gdb ./test
==4405== and then give GDB the following command
==4405==   target remote | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405
==4405== --pid is optional if only one valgrind process is running
==4405== 

(gdb) target remote | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405
Remote debugging using | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405
relaying data between gdb and process 4405
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.15.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
[Switching to Thread 4405]
0x0000000004001530 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x00000000004004a7 in main ()
(gdb) disassemble 
Dump of assembler code for function main:
   0x000000000040049c <+0>:	push   %rbp
   0x000000000040049d <+1>:	mov    %rsp,%rbp
   0x00000000004004a0 <+4>:	mov    %edi,-0x4(%rbp)
   0x00000000004004a3 <+7>:	mov    %rsi,-0x10(%rbp)
=> 0x00000000004004a7 <+11>:	lock xadd %dl,(%rax)
   0x00000000004004ab <+15>:	mov    $0x0,%eax
   0x00000000004004b0 <+20>:	pop    %rbp
   0x00000000004004b1 <+21>:	retq   
End of assembler dump.
(gdb)

--- Additional comment from jakub on 2012-10-16 05:09:34 EDT ---

Created attachment 628051 [details]
valgrind-xaddb.patch

I'm probably missing something obvious, but to me it looks like xaddb handling in valgrind 3.7.x and earlier was misplaced and with AVX merge it got commented out.

--- Additional comment from mjw on 2012-10-16 05:39:15 EDT ---

Confirmed with upstream. "it got disabled during the massive reorganisation of that insn decoder last year, and never got re-enabled"

https://bugs.kde.org/show_bug.cgi?id=307106
Comment 2 Mark Wielaard 2012-10-16 12:15:46 UTC 
This is a x86_64 issue only. The simplest (bogus) binary to show this issue is:

int
main (int argc, char **argv)
{
  asm("xaddb %dl,(%rax)");
  return 0;
}

$ gcc -g -o test test.c

$ valgrind --tool=none ./test
[...]
==9187== Command: /tmp/test
==9187== 
vex amd64->IR: unhandled instruction bytes: 0xF 0xC0 0x10 0xB8 0x0 0x0 0x0 0x0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==9187== valgrind: Unrecognised instruction at address 0x4004a7.
Comment 3 Mark Wielaard 2012-10-16 12:32:12 UTC 
From the clone of this bug https://bugzilla.redhat.com/show_bug.cgi?id=866943

--- Comment #5 from Jakub Jelinek <jakub> ---
And even better:

int
main ()
{
  char a = 8;
  char b = 9;
  asm volatile ("lock xaddb %%dl, (%%rax)" : "=m" (b), "+d" (a) : "a" (&b) :
"memory");
  return 0;
}

because xaddb returns in %%dl the value read from memory before the atomic
modification.
Comment 6 errata-xmlrpc 2013-02-21 08:52:08 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0347.html