| Summary: | disInstr(arm): unhandled instruction: 0xF1010200 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Jeffrey Walton <noloader> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | peter.maydell |
| Priority: | NOR | ||
| Version: | 3.12 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Can you use objdump -d to find out what instruction that actually is? 0xF1010200 is "SETEND BE". This is almost certainly the optimized-for-1176 32-bit ARM raspberry pi memcmp. See bug #322935, closed WONTFIX in 2013. (This is a silly memcmp implementation for a Cortex-A53, where SETEND is rather more expensive than it was on the 1176, so the ideal fix would be to get the OS not to use it.) (In reply to Peter Maydell from comment #2) > 0xF1010200 is "SETEND BE". This is almost certainly the optimized-for-1176 > 32-bit ARM raspberry pi memcmp. See bug #322935, closed WONTFIX in 2013. Ah, thanks Peter. Is there a way to get Valgrind's portion of the bug tracker to return search results that are no longer open? Or at least include the ones marked as "won't fix"? (Does the bug tracker have a per-project configuration). I guess the high level observation is: why is the bug tracker not returning exact hits when I search for terms like "unhandled instruction 0xF1010200" (without the quotes). Returning the results would save us both time and energy. (In reply to Jeffrey Walton from comment #3) > Is there a way to get Valgrind's portion of the bug tracker to return search > results that are no longer open? Or at least include the ones marked as > "won't fix"? (Does the bug tracker have a per-project configuration). The simple search box only looks for open bugs, but you can always use a more complicated search query if you want to find closed bugs too. For instance if you start at https://bugs.kde.org/query.cgi you can select Status All, Product valgrind, Words 0xF1010200, which brings up the closed bug as well as the open ones. Note, I added an additional comment to bug 322935 just now, that tries to give a bit more perspective to the issue. *** This bug has been marked as a duplicate of bug 322935 *** |
I'm working on an Raspberry Pi 3. Its an ARMv8 device with a Broadcom SoC based on A53 core. The Broadcom SoC has ASIMD and CRC32, but it lacks Crypto extensions. The OS is 32-bit Raspbian with hard floats. The program below is Jack Lloyd's test driver program for Botan. The flags used to compile the the library and test program are `-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard`. $ valgrind ./botan-test ==842== Memcheck, a memory error detector ==842== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==842== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==842== Command: ./botan-test ==842== disInstr(arm): unhandled instruction: 0xF1010200 cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) ==842== valgrind: Unrecognised instruction at address 0x485f6f4. ==842== at 0x485F6F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so) ==842== Your program just tried to execute an instruction that Valgrind ==842== did not recognise. There are two possible reasons for this. ==842== 1. Your program has a bug and erroneously jumped to a non-code ==842== location. If you are running Memcheck and you just saw a ==842== warning about a bad jump, it's probably your program's fault. ==842== 2. The instruction is legitimate but Valgrind doesn't handle it, ==842== i.e. it's Valgrind's fault. If you think this is the case or ==842== you are not sure, please let us know and we'll try to fix it. ==842== Either way, Valgrind will now raise a SIGILL signal which will ==842== probably kill your program. ==842== ==842== Process terminating with default action of signal 4 (SIGILL) ==842== Illegal opcode at address 0x485F6F4 ==842== at 0x485F6F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so) ==842== ==842== HEAP SUMMARY: ==842== in use at exit: 776 bytes in 39 blocks ==842== total heap usage: 39 allocs, 0 frees, 776 bytes allocated ==842== ==842== LEAK SUMMARY: ==842== definitely lost: 0 bytes in 0 blocks ==842== indirectly lost: 0 bytes in 0 blocks ==842== possibly lost: 0 bytes in 0 blocks ==842== still reachable: 776 bytes in 39 blocks ==842== of which reachable via heuristic: ==842== stdstring : 752 bytes in 38 blocks ==842== suppressed: 0 bytes in 0 blocks ==842== Rerun with --leak-check=full to see details of leaked memory ==842== ==842== For counts of detected and suppressed errors, rerun with: -v ==842== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction ---------- A related report is http://bugs.kde.org/show_bug.cgi?id=358620. The 620 issue is for the unhandled syscall, and does not appear to address the unhandled instruction since its still showing up in the latest SVN. ---------- $ svn info Path: . Working Copy Root Path: /home/jwalton/valgrind URL: svn://svn.valgrind.org/valgrind/trunk Relative URL: ^/trunk Repository Root: svn://svn.valgrind.org/valgrind Repository UUID: a5019735-40e9-0310-863c-91ae7b9d1cf9 Revision: 15929 Node Kind: directory Schedule: normal Last Changed Author: sewardj Last Changed Rev: 15929 Last Changed Date: 2016-08-05 13:22:21 -0400 (Fri, 05 Aug 2016)