[valgrind] [Bug 372358] vex amd64->IR: unhandled instruction bytes: 0xC5 0xFA 0x7F 0x45 0x80 0xC5 0xFA 0x7F 0x4D 0x90

[Patrick J . LoPresti]

https://bugs.kde.org/show_bug.cgi?id=372358

Patrick J. LoPresti  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Patrick J. LoPresti  ---
Sorry, Julian, my mistake.

Yes, I was running on a RHEL 5.x system whose kernel does not enable AVX
support. When run outside Valgrind it gets "illegal instruction" (of course).

Sorry again for the bogus report.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 372358] vex amd64->IR: unhandled instruction bytes: 0xC5 0xFA 0x7F 0x45 0x80 0xC5 0xFA 0x7F 0x4D 0x90

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=372358

--- Comment #4 from Julian Seward  ---
Are you running this test on a machine whose CPUID says that AVX isn't
supported?  Does the test actually run natively on the machine?  I'm pretty
sure VEX will decline to decode the insn if the surrounding Valgrind tells
it this is not an AVX capable cpu.  That would explain it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 372358] vex amd64->IR: unhandled instruction bytes: 0xC5 0xFA 0x7F 0x45 0x80 0xC5 0xFA 0x7F 0x4D 0x90

[Patrick J . LoPresti]

https://bugs.kde.org/show_bug.cgi?id=372358

--- Comment #3 from Patrick J. LoPresti  ---
Well, that is weird... I am not making it up :-)

I was using the 3.12.0 release. Is it possible this has been fixed in SVN?

I will check, but probably not until next week. Thanks, Julian

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 372358] vex amd64->IR: unhandled instruction bytes: 0xC5 0xFA 0x7F 0x45 0x80 0xC5 0xFA 0x7F 0x4D 0x90

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=372358

--- Comment #2 from Julian Seward  ---
I can't reproduce this.  Are you sure this is right?  I tried 
thusly:

int main ( void )
{
   __asm__ __volatile__(
  ".byte 0xC5, 0xFA, 0x7F, 0x45, 0x80, 0xC5, 0xFA, 0x7F, 0x4D, 0x90"
  ::: "cc","memory");
   return 0;
}

giving

004004f6 :
  4004f6:   c5 fa 7f 45 80  vmovdqu %xmm0,-0x80(%rbp)
  4004fb:   c5 fa 7f 4d 90  vmovdqu %xmm1,-0x70(%rbp)
  400500:   b8 00 00 00 00  mov$0x0,%eax
  400505:   c3  retq   
  400506:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  40050d:   00 00 00 

(sure, there are 2 complete insns there, but it doesn't matter)

and although it segfaults (as it does natively), it runs correctly
through  the front end:

$ ./zzz6
Segmentation fault (core dumped)

$ v312BRANCH ./zzz6
==5911== Memcheck, a memory error detector
==5911== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5911== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==5911== Command: ./zzz6
==5911== 
==5911== 
==5911== Process terminating with default action of signal 11 (SIGSEGV)
==5911==  Bad permissions for mapped region at address 0x400490
==5911==at 0x4004F6: main (zzz6.c:3)
==5911== 
==5911== HEAP SUMMARY:
==5911== in use at exit: 0 bytes in 0 blocks
==5911==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5911== 
==5911== All heap blocks were freed -- no leaks are possible
==5911== 
==5911== For counts of detected and suppressed errors, rerun with: -v
==5911== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 372358] vex amd64->IR: unhandled instruction bytes: 0xC5 0xFA 0x7F 0x45 0x80 0xC5 0xFA 0x7F 0x4D 0x90

[Patrick J . LoPresti]

https://bugs.kde.org/show_bug.cgi?id=372358

--- Comment #1 from Patrick J. LoPresti  ---
I meant "GDB" not "GCC" obviously.

-- 
You are receiving this mail because:
You are watching all bug changes.