|
From: Francois-Xavier K. <fra...@hp...> - 2006-11-08 11:48:05
|
Hello, Anyone interested in this opcode? This is object code compiled with no optimization support (-O0) using ICC 9.1.044 (the latest Intel C/C++ compiler for Linux). Machine in a Pentium4 (Prescott) with HT. vex x86->IR: unhandled instruction bytes: 0x67 0xE3 0x67 0xF ==3595== Your program just tried to execute an instruction that Valgrind ==3595== did not recognise. There are two possible reasons for this. ==3595== 1. Your program has a bug and erroneously jumped to a non-code ==3595== location. If you are running Memcheck and you just saw a ==3595== warning about a bad jump, it's probably your program's fault. ==3595== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3595== i.e. it's Valgrind's fault. If you think this is the case or ==3595== you are not sure, please let us know. ==3595== Either way, Valgrind will now raise a SIGILL signal which will ==3595== probably kill your program. ==3595== ==3595== Process terminating with default action of signal 4 (SIGILL): dumping core ==3595== Illegal opcode at address 0x5A4932D ==3595== at 0x5A4932D: (within /home_local/fxk/build/media1.0_fxk_linux-i386-fedora-core3_icc-debug/ippsamples/speech-coding/lib/.libs/libippsamples_speech.so.0.0.0) ==3595== br. -- Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 OpenCall Business Unit -- OCBU / //_/ Fax:+33 (0)4 76 14 51 62 Media-Processing Engineering / http://www.hp.com/go/opencall i n v e n t |
|
From: Tom H. <to...@co...> - 2006-11-08 12:59:27
|
In message <455...@hp...>
Francois-Xavier KOWALSKI <fra...@hp...> wrote:
> Anyone interested in this opcode? This is object code compiled with no
> optimization support (-O0) using ICC 9.1.044 (the latest Intel C/C++
> compiler for Linux). Machine in a Pentium4 (Prescott) with HT.
>
> vex x86->IR: unhandled instruction bytes: 0x67 0xE3 0x67 0xF
Lovely... That's a jcxz instruction (jecxz with an address size
override prefix so it only considers sixteen bits of the register
instead of all thirty two).
There is no code to spot address size override prefixed in valgrind
at the moment, so that instruction will fail.
Can you raise a bug on the bug tracker for this please.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Francois-Xavier K. <fra...@hp...> - 2006-11-12 23:29:21
|
Tom Hughes wrote: > In message <455...@hp...> > Francois-Xavier KOWALSKI <fra...@hp...> wrote: > > >> Anyone interested in this opcode? This is object code compiled with no >> optimization support (-O0) using ICC 9.1.044 (the latest Intel C/C++ >> compiler for Linux). Machine in a Pentium4 (Prescott) with HT. >> >> vex x86->IR: unhandled instruction bytes: 0x67 0xE3 0x67 0xF >> > > Lovely... That's a jcxz instruction (jecxz with an address size > override prefix so it only considers sixteen bits of the register > instead of all thirty two). > > There is no code to spot address size override prefixed in valgrind > at the moment, so that instruction will fail. > > Can you raise a bug on the bug tracker for this please. > www.valgrind.org seems to be down. I tried to locate a bug-tracker on SourceForge -- as this ML is hosted on SourceForge -- but there does not seem to be any bugtracker for valgrind. Any direct URL to the bug-tracker? TIA -- Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 OpenCall Business Unit -- OCBU / //_/ Fax:+33 (0)4 76 14 51 62 Media-Processing Engineering / http://www.hp.com/go/opencall i n v e n t |
|
From: Julian S. <js...@ac...> - 2006-11-12 23:44:50
|
> > Lovely... That's a jcxz instruction (jecxz with an address size
> > override prefix so it only considers sixteen bits of the register
> > instead of all thirty two).
> >
> > There is no code to spot address size override prefixed in valgrind
> > at the moment, so that instruction will fail.
The amd64 front end has this
case 0x67: pfx |= PFX_ASO; break;
so it is handleable. I'll get to it.
> www.valgrind.org seems to be down.
Yes. I guess apache bombed or something.
> I tried to locate a bug-tracker on
> SourceForge -- as this ML is hosted on SourceForge -- but there does not
> seem to be any bugtracker for valgrind. Any direct URL to the bug-tracker?
We use the KDE bug tracker. Go to bugs.kde.org and file a bug for the
'valgrind' component.
J
|
|
From: Tom H. <to...@co...> - 2006-11-12 23:46:55
|
In message <455...@hp...>
Francois-Xavier KOWALSKI <fra...@hp...> wrote:
> www.valgrind.org seems to be down. I tried to locate a bug-tracker on
> SourceForge -- as this ML is hosted on SourceForge -- but there does not
> seem to be any bugtracker for valgrind. Any direct URL to the bug-tracker?
http://bugs.kde.org/enter_valgrind_bug.cgi
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-11-16 01:05:59
|
On Sunday 12 November 2006 08:48, Francois-Xavier KOWALSKI wrote:
> Tom Hughes wrote:
> > In message <455...@hp...>
> >
> > Francois-Xavier KOWALSKI <fra...@hp...> wrote:
> >> Anyone interested in this opcode? This is object code compiled with no
> >> optimization support (-O0) using ICC 9.1.044 (the latest Intel C/C++
> >> compiler for Linux). Machine in a Pentium4 (Prescott) with HT.
> >>
> >> vex x86->IR: unhandled instruction bytes: 0x67 0xE3 0x67 0xF
> >
> > Lovely... That's a jcxz instruction (jecxz with an address size
> > override prefix so it only considers sixteen bits of the register
> > instead of all thirty two).
Francois-Xavier, can you try the following patch?
J
Index: priv/guest-x86/toIR.c
===================================================================
--- priv/guest-x86/toIR.c (revision 1674)
+++ priv/guest-x86/toIR.c (working copy)
@@ -11174,6 +11174,27 @@
DIP("j%sz 0x%x\n", nameIReg(sz, R_ECX), d32);
break;
+ case 0x67: /* then 0xE3: JCXZ */
+ if (getIByte(delta) == 0xE3) {
+ delta++;
+ sz = 2;
+ d32 = (((Addr32)guest_EIP_bbstart)+delta+1) + getSDisp8(delta);
+ delta++;
+ ty = szToITy(sz);
+ stmt( IRStmt_Exit(
+ binop(mkSizedOp(ty,Iop_CmpEQ8),
+ getIReg(sz,R_ECX),
+ mkU(ty,0)),
+ Ijk_Boring,
+ IRConst_U32(d32))
+ );
+
+ DIP("j%sz 0x%x\n", nameIReg(sz, R_ECX), d32);
+ break;
+ } else {
+ goto decode_failure;
+ }
+
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 */
|
|
From: Francois-Xavier K. <fra...@hp...> - 2006-11-27 16:51:05
|
Julian Seward wrote: > On Sunday 12 November 2006 08:48, Francois-Xavier KOWALSKI wrote: > >> Tom Hughes wrote: >> >>> In message <455...@hp...> >>> >>> Francois-Xavier KOWALSKI <fra...@hp...> wrote: >>> >>>> Anyone interested in this opcode? This is object code compiled with no >>>> optimization support (-O0) using ICC 9.1.044 (the latest Intel C/C++ >>>> compiler for Linux). Machine in a Pentium4 (Prescott) with HT. >>>> >>>> vex x86->IR: unhandled instruction bytes: 0x67 0xE3 0x67 0xF >>>> >>> Lovely... That's a jcxz instruction (jecxz with an address size >>> override prefix so it only considers sixteen bits of the register >>> instead of all thirty two). >>> > > Francois-Xavier, can you try the following patch? > Oooops. I did not see your answer (automatically sorted out by Thunderbird...) I will try it right away. Thanks a lot -- Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 OpenCall Business Unit -- OCBU / //_/ Fax:+33 (0)4 76 14 51 62 Media-Processing Engineering / http://www.hp.com/go/opencall i n v e n t |
|
From: Francois-Xavier K. <fra...@hp...> - 2006-11-27 17:47:25
|
Francois-Xavier KOWALSKI wrote: > Julian Seward wrote: >> [...] >> Francois-Xavier, can you try the following patch? > > Oooops. I did not see your answer (automatically sorted out by > Thunderbird...) I will try it right away. It worked (patch applied on top of 3.2.1). Thanks. Now I have the next one... :-\ I have switched from ICC to GCC, but I still use IPP-compiled code (IPP: Intel Performance Primitives) which seem to use some other new instructions. My box is still Pentium4/Prescott, running FC3 with 32-bits kernel & HT turned on (in case that matters). vex x86->IR: unhandled instruction bytes: 0xF2 0xF 0xF0 0x6 ==27913== Your program just tried to execute an instruction that Valgrind ==27913== did not recognise. There are two possible reasons for this. ==27913== 1. Your program has a bug and erroneously jumped to a non-code ==27913== location. If you are running Memcheck and you just saw a ==27913== warning about a bad jump, it's probably your program's fault. ==27913== 2. The instruction is legitimate but Valgrind doesn't handle it, ==27913== i.e. it's Valgrind's fault. If you think this is the case or ==27913== you are not sure, please let us know. ==27913== Either way, Valgrind will now raise a SIGILL signal which will ==27913== probably kill your program. ==27913== ==27913== Process terminating with default action of signal 4 (SIGILL): dumping core ==27913== Illegal opcode at address 0x816E7A5 ==27913== at 0x816E7A5: (within /home_local/fxk/build/media1.0_fxk_linux-i386-fedora-core3_debug/softdsp/code/av_trans/vtrans/tes t/file/.libs/lt-vtrans) ==27913== by 0x815B34B: t7_ippiMC16x16_8u_C1 (in /home_local/fxk/build/media1.0_fxk_linux-i386-fedora-core3_debug/softdsp/code/av _trans/vtrans/test/file/.libs/lt-vtrans) Do you want me to fill a separated bug-report in <http://bugs.kde.org/enter_valgrind_bug.cgi>? Thanks. -- Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 OpenCall Business Unit -- OCBU / //_/ Fax:+33 (0)4 76 14 51 62 Media-Processing Engineering / http://www.hp.com/go/opencall i n v e n t |