Summary: | Internal Valgrind error on 64-bit instruction executed in 32-bit mode | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Carl Love <cel> |
Component: | vex | Assignee: | Julian Seward <jseward> |
Status: | CLOSED FIXED | ||
Severity: | normal | CC: | mark, maynardj |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Fix missing checks for 64-bit instructions operating in 32-bit mode
VEX: Add and use Ijk_SigILL coregrind: Handle VEX_TRC_JMP_SIGILL |
Description
Carl Love
2012-10-17 19:23:22 UTC
adding Maynard to the cc list This is also https://bugzilla.redhat.com/show_bug.cgi?id=810992 which has an example of the hand coded assembly that openssl uses that triggers this bug in comment number 6: https://bugzilla.redhat.com/show_bug.cgi?id=810992#c6 Created attachment 74638 [details]
Fix missing checks for 64-bit instructions operating in 32-bit mode
The attached patch adds the missing 32-bit mode checks to the 64-bit instructions. The number of regression test passes and failures is not changed by this patch.
Please review the patch and post comments. Thanks.
Looks fine to me. Please commit. Committed the attached patch to fix the VEX code. Vex committed revision 2558 Committed a fix to the memcheck/tests/ppc32/power_ISA2_05.c test to remove the 64-bit class instruction from the 32-bit test. The expected output for the test was also updated. Valgrind committed revision 13091. The fix works, but is there any way to suppress all the output? disInstr(ppc): unhandled instruction: 0x78000022 primary 30(0x1E), secondary 34(0x22) ==30163== valgrind: Unrecognised instruction at address 0xfd0d294. ==30163== at 0xFD0D294: ??? (in /usr/lib/libcrypto.so.1.0.1c) ==30163== by 0xFD93B93: OPENSSL_add_all_algorithms_noconf (in /usr/lib/libcrypto.so.1.0.1c) ==30163== by 0x100005DB: main (in /home/test/testppc) ==30163== Your program just tried to execute an instruction that Valgrind ==30163== did not recognise. There are two possible reasons for this. ==30163== 1. Your program has a bug and erroneously jumped to a non-code ==30163== location. If you are running Memcheck and you just saw a ==30163== warning about a bad jump, it's probably your program's fault. ==30163== 2. The instruction is legitimate but Valgrind doesn't handle it, ==30163== i.e. it's Valgrind's fault. If you think this is the case or ==30163== you are not sure, please let us know and we'll try to fix it. ==30163== Either way, Valgrind will now raise a SIGILL signal which will ==30163== probably kill your program. The above is slightly misleading, the instruction was recognized, valgrind just decided (correctly) to throw a SIGILL in response. It is also printed when using -q to run silently, making it not very silent anymore :) Created attachment 74889 [details] VEX: Add and use Ijk_SigILL > The above is slightly misleading, the instruction was recognized, valgrind just decided (correctly) > to throw a SIGILL in response. It is also printed when using -q to run silently, making it not very > silent anymore :) How about making it possible to be explicit about (expected) illegal instructions like in this patch? Created attachment 74890 [details]
coregrind: Handle VEX_TRC_JMP_SIGILL
coregrind part for VEX change
(In reply to comment #7) > How about making it possible to be explicit about (expected) illegal > instructions like in this patch? After some discussion that wasn't the right way to go about this. See https://bugs.kde.org/show_bug.cgi?id=309425 for an alternative (none-ppc-specific) solution. |