fb@alchemy:~/src/test$ valgrind ls ==4299== Memcheck, a memory error detector ==4299== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==4299== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==4299== Command: ls ==4299== vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xCA 0x3 0x1D 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=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==4299== valgrind: Unrecognised instruction at address 0x39f3a11076. ==4299== at 0x39F3A11076: _dl_allocate_tls_storage (in /lib64/ld-2.15.so) ==4299== by 0x39F3A01078: init_tls.part.3 (in /lib64/ld-2.15.so) ==4299== by 0x39F3A03BC9: dl_main (in /lib64/ld-2.15.so) ==4299== by 0x39F3A147C6: _dl_sysdep_start (in /lib64/ld-2.15.so) ==4299== by 0x39F3A04FE2: _dl_start (in /lib64/ld-2.15.so) ==4299== by 0x39F3A01707: ??? (in /lib64/ld-2.15.so) ==4299== Your program just tried to execute an instruction that Valgrind ==4299== did not recognise. There are two possible reasons for this. ==4299== 1. Your program has a bug and erroneously jumped to a non-code ==4299== location. If you are running Memcheck and you just saw a ==4299== warning about a bad jump, it's probably your program's fault. ==4299== 2. The instruction is legitimate but Valgrind doesn't handle it, ==4299== i.e. it's Valgrind's fault. If you think this is the case or ==4299== you are not sure, please let us know and we'll try to fix it. ==4299== Either way, Valgrind will now raise a SIGILL signal which will ==4299== probably kill your program. ==4299== ==4299== Process terminating with default action of signal 4 (SIGILL) ==4299== Illegal opcode at address 0x39F3A11076 ==4299== at 0x39F3A11076: _dl_allocate_tls_storage (in /lib64/ld-2.15.so) ==4299== by 0x39F3A01078: init_tls.part.3 (in /lib64/ld-2.15.so) ==4299== by 0x39F3A03BC9: dl_main (in /lib64/ld-2.15.so) ==4299== by 0x39F3A147C6: _dl_sysdep_start (in /lib64/ld-2.15.so) ==4299== by 0x39F3A04FE2: _dl_start (in /lib64/ld-2.15.so) ==4299== by 0x39F3A01707: ??? (in /lib64/ld-2.15.so) ==4299== Jump to the invalid address stated on the next line ==4299== at 0x526: ??? ==4299== Address 0x526 is not stack'd, malloc'd or (recently) free'd ==4299== ==4299== ==4299== Process terminating with default action of signal 11 (SIGSEGV) ==4299== Bad permissions for mapped region at address 0x526 ==4299== at 0x526: ??? ==4299== ==4299== HEAP SUMMARY: ==4299== in use at exit: 0 bytes in 0 blocks ==4299== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==4299== ==4299== All heap blocks were freed -- no leaks are possible ==4299== ==4299== For counts of detected and suppressed errors, rerun with: -v ==4299== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault An objdump of ld-2.15.so shows this: 39f3a11076: 8f ea f8 10 ca 03 1d bextr $0x1d03,%rdx,%rcx My processor is an AMD FX-8350; pretty much everything on my system is compiled with --march=native. Reproducible: Always Steps to Reproduce: 1. Try to use valgrind 2. 3. Actual Results: :<
Created attachment 82347 [details] support for TBM bextr
Thank you for the patch, however it does build with current (VEX r2772) code: make[3]: Entering directory `/home/petr/valgrind-devel/VEX' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1 -Ipriv -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -Wbad-function-cast -Wcast-qual -Wcast-align -fstrict-aliasing -Wno-long-long -Wwrite-strings -fno-stack-protector -MT priv/libvex_amd64_linux_a-guest_amd64_toIR.o -MD -MP -MF priv/.deps/libvex_amd64_linux_a-guest_amd64_toIR.Tpo -c -o priv/libvex_amd64_linux_a-guest_amd64_toIR.o `test -f 'priv/guest_amd64_toIR.c' || echo './'`priv/guest_amd64_toIR.c priv/guest_amd64_toIR.c: In function ‘dis_ESC_0F3A__XOP’: priv/guest_amd64_toIR.c:30626:10: error: unknown type name ‘UCHAR’ priv/guest_amd64_toIR.c:30662:30: error: too many arguments to function ‘binop’ priv/guest_amd64_toIR.c:251:16: note: declared here priv/guest_amd64_toIR.c:30662:49: error: expected ‘)’ before ‘;’ token priv/guest_amd64_toIR.c:30663:13: error: too few arguments to function ‘binop’ priv/guest_amd64_toIR.c:251:16: note: declared here priv/guest_amd64_toIR.c:30663:13: error: expected ‘)’ before ‘}’ token priv/guest_amd64_toIR.c:30663:13: error: expected ‘;’ before ‘}’ token make[3]: *** [priv/libvex_amd64_linux_a-guest_amd64_toIR.o] Error 1 It actually does build even with r2763 which the patch has been diffed against.
Created attachment 82427 [details] support for TBM bextr This is the original patch with three syntax errors fixed: @@ -50,7 +50,7 @@ + case 0x10: + if ((pfx & PFX_VEXnvvvv) == 0 && 0==getVexL(pfx)/*LZ*/) { + Int size = getRexW(pfx) ? 8 : 4, ctrl; -+ UCHAR start, len, opsize; ++ UChar start, len, opsize; + IRType ty = szToITy(size); + IRTemp dst = newTemp(ty); + IRTemp src1 = newTemp(ty); @@ -85,8 +85,8 @@ + binop( + mkSizedOp(ty,Iop_Shl8), + mkexpr(src1), -+ mkU8(opsize-start-len), -+ mkU8(opsize - len)); ++ mkU8(opsize-start-len)), ++ mkU8(opsize - len))); + } + } else { + if (start < opsize) { I can confirm it fixes the reported problem for me.
The attached patch also fixed the problem for me. I can confirm the problem still exist. My ld’s version was 2.20.
I forgot to add valgrind’s version was 3.10.1 and that I’m on AMD APU A10 5800K.
Note, this is still an issue with 3.12.0, 3.13.0 and whichever version is the tip of the 3.14.0 version right now.
The patch by "Petr Pisar" has been attached also to bug 381819. *** This bug has been marked as a duplicate of bug 381819 ***