| Summary: | vex amd64->IR: unhandled instruction bytes: 0xC5 0xFA 0x7F 0x45 0x80 0xC5 0xFA 0x7F 0x4D 0x90 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Patrick J. LoPresti <lopresti> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 3.12 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Patrick J. LoPresti
2016-11-11 19:13:42 UTC
I meant "GDB" not "GCC" obviously. 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
00000000004004f6 <main>:
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 00 nopw %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)
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 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. 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. |