https://bugs.kde.org/show_bug.cgi?id=366464

            Bug ID: 366464
           Summary: disInstr(arm): unhandled instruction: 0xF1010200
           Product: valgrind
           Version: 3.12 SVN
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: vex
          Assignee: jsew...@acm.org
          Reporter: noloa...@gmail.com

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)

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to