Bug 366464 - disInstr(arm): unhandled instruction: 0xF1010200
Summary: disInstr(arm): unhandled instruction: 0xF1010200
Status: RESOLVED DUPLICATE of bug 322935
Alias: None
Product: valgrind
Classification: Unclassified
Component: vex (show other bugs)
Version: 3.12 SVN
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-06 00:16 UTC by Jeffrey Walton
Modified: 2016-09-15 06:44 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Walton 2016-08-06 00:16:54 UTC
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)
Comment 1 Julian Seward 2016-08-06 12:25:33 UTC
Can you use objdump -d to find out what instruction that actually is?
Comment 2 Peter Maydell 2016-08-07 19:25:52 UTC
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.)
Comment 3 Jeffrey Walton 2016-08-07 19:31:39 UTC
(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.
Comment 4 Peter Maydell 2016-08-07 19:42:11 UTC
(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.
Comment 5 Julian Seward 2016-09-15 06:44:43 UTC
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 ***