| Summary: | LibVEX 'Assertion szBlg2 <= 3' | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Claus Strasburger <c+kde> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | c+kde |
| Priority: | NOR | ||
| Version: | 3.12 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Valgrind log | ||
|
Description
Claus Strasburger
2016-11-22 16:01:37 UTC
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. |