Created attachment 102391 [details] Valgrind log Hello, I am running Valgrind 3.12.0, compiled from source using ./configure --prefix=/usr/local/ && make -j4 && make install On a Raspberry Pi 3 B, Raspbian Jessie. Kernel 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux Running any program linked to libcrypto produces the crash detailed in the attachment below. Example program which triggers the bug: --- #include <stdio.h> int main(int argc, char **argv) { printf("Hello\n"); return 0; } --- Compile and run with: gcc -o test test.c -lcrypto && valgrind ./test Installed libssl is: libssl1.0.0 version 1.0.1t-1+deb8u5 from http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Thanks, Claus Strasburger
Ach, the logic there that verifies whether the instruction decode is valid, is wrong. Try this: change // Paranoia .. vassert(szBlg2 <= 3); if (szBlg2 < 3) { vassert(tt2 == 16/*invalid*/); } else { vassert(tt2 <= 14); } if (isLoad) { vassert(dd == 16/*invalid*/); } else { vassert(dd <= 14); } // If we're still good even after all that, generate the IR. by wrapping "if (gate) { .. }" around it: if (gate) { // Paranoia .. vassert(szBlg2 <= 3); if (szBlg2 < 3) { vassert(tt2 == 16/*invalid*/); } else { vassert(tt2 <= 14); } if (isLoad) { vassert(dd == 16/*invalid*/); } else { vassert(dd <= 14); } // If we're still good even after all that, generate the IR. } This isn't a proper fix, though. Can you use objdump to find the insn it is failing on? I'll need that to test it properly.
Okay, I used LD_DEBUG=files to subtract the base address of libcrypto, and got 414b0 (x->). which seems to be the return of OPENSSL_cpuid_setup (??) 414a4: ebfffa93 bl 3fef8 <__sigsetjmp@plt> 414a8: e3500000 cmp r0, #0 414ac: 1a000006 bne 414cc <OPENSSL_cpuid_setup+0x18c> x->414b0: eb000e4c bl 44de8 <OPENSSL_init+0x84> 414b4: e59f3068 ldr r3, [pc, #104] ; 41524 <OPENSSL_cpuid_setup+0x1e4> 414b8: e59d2004 ldr r2, [sp, #4] 414bc: e7922003 ldr r2, [r2, r3] I took the address from "Thread 1: status = VgTs_Runnable (lwpid 27114) ==27114== at 0x48B54B0: OPENSSL_cpuid_setup (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0)" ---- Applying the fix you mentioned gets me farther, until: disInstr(arm): unhandled instruction: 0xEE190F1D cond=14(0xE) 27:20=225(0xE1) 4:4=1 3:0=13(0xD) ==30349== valgrind: Unrecognised instruction at address 0x48b8de8 (minus base address: 44de8, y->). 44dac: e5930000 ldr r0, [r3] 44db0: e2100002 ands r0, r0, #2 44db4: 012fff1e bxeq lr 44db8: ea00000a b 44de8 <OPENSSL_init+0x84> 44dbc: 0011d254 andseq sp, r1, r4, asr r2 44dc0: 0000224c andeq r2, r0, ip, asr #4 ... 44de0: f26ee1fe vorr q15, q15, q15 44de4: e12fff1e bx lr y->44de8: ee190f1d mrc 15, 0, r0, cr9, cr13, {0} 44dec: e12fff1e bx lr Which is the address we were trying to jump to the last attempt... Does that help?
Fixed, vex r3289.
Thanks! I can verify that gets me past the OpenSSL setup. I'm finding another unhandled instruction (and I'm guessing there will be more -- this one is 0xFEBB0B40, VRINTM.f64), in code generated with -mcpu=cortex-a53 -mfpu=neon-fp-armv8 (for the Raspberry Pi 3, gcc 4.9.2) Should I open new bugs for these?
(In reply to Claus Strasburger from comment #4) > more -- this one is 0xFEBB0B40, VRINTM.f64), in code generated with > -mcpu=cortex-a53 -mfpu=neon-fp-armv8 (for the Raspberry Pi 3, gcc 4.9.2) > > Should I open new bugs for these? In general, new problems should go on new bug reports. Having a single bug report tracking multiple failures is confusing. In this particular case, try svn up-ing and trying again. Vex r3292 supports VRINTM.f64 and some other instructions -- as far as I can tell, all the instructions that "gcc-5.4 -mfpu=neon-fp-armv8".
> all the instructions that "gcc-5.4 -mfpu=neon-fp-armv8". += "generates."
Indeed, my tests are happy. You guys are awesome! Thanks for all the hard work.