|
From: Venefax <ve...@gm...> - 2008-04-24 16:08:13
|
In Valgrind 3.4.0 SVN, I load an application that uses the Intel multimedia instruction set and valgrind kills the app. It seems to be a valgrind bug based on the information provided by the trace. I can submit the binary. "vex amd64-IR: unhandled instruction bytes: 0x48 0xF 0x6F 0x6 0x48 0x83 ==3090== valgrind: Unrecognised instruction at address 0xC593778. ==3090== Your program just tried to execute an instruction that Valgrind ==3090== did not recognise. There are two possible reasons for this. ==3090== 1. Your program has a bug and erroneously jumped to a non-code ==3090== location. If you are running Memcheck and you just saw a ==3090== warning about a bad jump, it's probably your program's fault. ==3090== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3090== i.e. it's Valgrind's fault. If you think this is the case or ==3090== you are not sure, please let us know and we'll try to fix it. ==3090== Either way, Valgrind will now raise a SIGILL signal which will ==3090== probably kill your program. ==3090== ==3090== Process terminating with default action of signal 4 (SIGILL): dumping core ==3090== Illegal opcode at address 0xC593778 ==3090== at 0xC593778: (within /usr/lib/asterisk/modules/codec_g723.so) ==3090== by 0x99F76C9: ??? ==3090== by 0x99F75BF: ??? ==3090== by 0xC515FFF: ??? ==3090== by 0x400CC24: _dl_fixup (in /lib64/ld-2.5.so) ==3090== by 0x40127A1: _dl_runtime_resolve (in /lib64/ld-2.5.so) ==3090== by 0xC5918E1: u8_ippsLSFToLPC_G723_16s_I (in /usr/lib/asterisk/modules/codec_g723.so) ==3090== by 0xC54F825: u8_ippsLSFToLPC_G723_16s (in /usr/lib/asterisk/modules/codec_g723.so) ==3090== by 0xC52E84B: LSPInterpolation (in /usr/lib/asterisk/modules/codec_g723.so) ==3090== by 0xC52B6C1: apiG723Decode (in /usr/lib/asterisk/modules/codec_g723.so) ==3090== by 0xC52AB90: (within /usr/lib/asterisk/modules/codec_g723.so) ==3090== by 0x4F7B32: framein (translate.c:193) ==3090== ==3090== ERROR SUMMARY: 2458 errors from 11 contexts (suppressed: 5 from 1) ==3090== malloc/free: in use at exit: 889,818 bytes in 3,319 blocks. ==3090== malloc/free: 6,919 allocs, 3,600 frees, 3,825,708 bytes allocated. ==3090== For counts of detected errors, rerun with: -v ==3090== searching for pointers to 3,319 not-freed blocks. ==3090== checked 5,552,096 bytes. ==3090== ==3090== LEAK SUMMARY: ==3090== definitely lost: 917 bytes in 42 blocks. ==3090== possibly lost: 4,695 bytes in 29 blocks. ==3090== still reachable: 884,206 bytes in 3,248 blocks. ==3090== suppressed: 0 bytes in 0 blocks. ==3090== Rerun with --leak-check=full to see details of leaked memory |
> "vex amd64-IR: unhandled instruction bytes: 0x48 0xF 0x6F 0x6 0x48
> 0x83
Here's how to start making sense of such a report. Create a file of
assembler text that has those bytes, compile it, then disassemble it
as instructions:
----- foo.S
.byte 0x48,0xF,0x6F,0x6,0x48,0x83
.byte 0x90,0x90,0x90,0x90 # filler if the report stopped too soon
----- end foo.S
$ gcc -c foo.S
$ gdb foo.o
(gdb) x/i 0
0x0: rex.W movq (%rsi),%mm0
(gdb)q
So it's a 64-bit fetch ('q' means "quad": four 16-bit words [8086])
into an MMX register %mm0, and the opcode is modified with a prefix
"rex.W". So lookup in the CPU reference manual what the prefix
"rex.W" means when applied to a load of an MMX register from memory.
--
|
|
From: Venefax <ve...@gm...> - 2008-04-25 04:21:15
|
Dear John I am not a engineer. The developers of valgrind should look into this. I assume that they would want to have a complete instruction set in the product. I have no idea if assembler is a food or a plant. Maybe it would be easier to contact Intel and do it by the book. But thanks anyway. Federico -----Original Message----- From: John Reiser [mailto:jreiser@BitWagon.com] Sent: Friday, April 25, 2008 12:16 AM To: Venefax Cc: val...@li... Subject: Re: [Valgrind-users] Valgrind does not understand an Opcode > "vex amd64-IR: unhandled instruction bytes: 0x48 0xF 0x6F 0x6 0x48 > 0x83 Here's how to start making sense of such a report. Create a file of assembler text that has those bytes, compile it, then disassemble it as instructions: ----- foo.S .byte 0x48,0xF,0x6F,0x6,0x48,0x83 .byte 0x90,0x90,0x90,0x90 # filler if the report stopped too soon ----- end foo.S $ gcc -c foo.S $ gdb foo.o (gdb) x/i 0 0x0: rex.W movq (%rsi),%mm0 (gdb)q So it's a 64-bit fetch ('q' means "quad": four 16-bit words [8086]) into an MMX register %mm0, and the opcode is modified with a prefix "rex.W". So lookup in the CPU reference manual what the prefix "rex.W" means when applied to a load of an MMX register from memory. -- |
|
From: Nicholas N. <nj...@cs...> - 2008-04-25 11:37:14
|
On Fri, 25 Apr 2008, Venefax wrote: > I am not a engineer. The developers of valgrind should look into this. I > assume that they would want to have a complete instruction set in the > product. Unfortunately, having a complete instruction set is not as simple as it sounds. x86 and x86-64 have instruction sets that are an enormous, horrible mess. Furthermore, many compilers emit instructions containing undocumented combinations of elements and/or redundant elements. This means that, in practice, it isn't clear what "complete instuction set" means. Julian generally adds support for unhandled instructions to Valgrind as they are reported. If you could report the problem in Bugzilla, that would increase the chance of it being fixed. > I have no idea if assembler is a food or a plant. Maybe it would be easier > to contact Intel and do it by the book. But thanks anyway. An assembler translates assembly language to object code. It's an important part of the compilation pipeline and a useful thing for any programmer to know about. See http://en.wikipedia.org/wiki/Assembly_language#Assembler. Nick |
|
From: Julian S. <js...@ac...> - 2008-04-28 15:04:06
|
> "vex amd64-IR: unhandled instruction bytes: 0x48 0xF 0x6F 0x6 0x48 > 0x83 I can fix this, although it would be easier and faster if you had filed a bug report. Can you send me the file /usr/lib/asterisk/modules/codec_g723.so to look at? bzip2 it first, otherwise my spam filters are likely to block it. J |