Bug 388603

When reporting unsupported instructions please include the error message from valgrind as it includes important information that is useful for fixing the bug.

Sorry, I had already changed the code to remove the vfma.f32 instructions when I posted the bug.
I put a couple back and ran it for you.

==2033== Callgrind, a call-graph generating cache profiler
==2033== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==2033== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2033== Command: ./dronose /mnt/SDCARD/data/frames bb.txt
==2033== 
==2033== For interactive control, run 'callgrind_control -h'.
type = bb
roi_xmin = 404
roi_ymin = 103
roi_xmax = 457
roi_ymax = 184
nfrm = 260
disInstr(arm): unhandled instruction: 0xF20AECFA
                 cond=15(0xF) 27:20=32(0x20) 4:4=1 3:0=10(0xA)
==2033== valgrind: Unrecognised instruction at address 0x84494.
==2033==    at 0x84494: ExtractBestGradientARM_3(Gradient*, _IplImage*, _IplImage*, int, int) (fhog.cpp:486)
==2033==    by 0x8508F: getFeatureMaps(_IplImage const*, int, CvLSVMFeatureMapCaskade**) (fhog.cpp:619)
==2033==    by 0x777D7: KCFTracker::getFeatures(cv::Mat const&, bool, float, KCFTracker::SizePatch&) (kcftracker.cpp:616)
==2033==    by 0x7C67B: KCFTracker::init(cv::Rect_<int> const&, cv::Mat) (kcftracker.cpp:121)
==2033==    by 0x73613: AltumTracker::setRoi(cv::Rect_<int>, cv::Mat) (altumtracker.cpp:97)
==2033==    by 0x6B087: selector::setRoiRunTracker(int, int, int, int) (dronose.cpp:88)
==2033==    by 0x694BF: main (dronose.cpp:320)
==2033== Your program just tried to execute an instruction that Valgrind
==2033== did not recognise.  There are two possible reasons for this.
==2033== 1. Your program has a bug and erroneously jumped to a non-code
==2033==    location.  If you are running Memcheck and you just saw a
==2033==    warning about a bad jump, it's probably your program's fault.
==2033== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2033==    i.e. it's Valgrind's fault.  If you think this is the case or
==2033==    you are not sure, please let us know and we'll try to fix it.
==2033== Either way, Valgrind will now raise a SIGILL signal which will
==2033== probably kill your program.
==2033== 
==2033== Process terminating with default action of signal 4 (SIGILL)
==2033==  Illegal opcode at address 0x84494
==2033==    at 0x84494: ExtractBestGradientARM_3(Gradient*, _IplImage*, _IplImage*, int, int) (fhog.cpp:486)
==2033==    by 0x8508F: getFeatureMaps(_IplImage const*, int, CvLSVMFeatureMapCaskade**) (fhog.cpp:619)
==2033==    by 0x777D7: KCFTracker::getFeatures(cv::Mat const&, bool, float, KCFTracker::SizePatch&) (kcftracker.cpp:616)
==2033==    by 0x7C67B: KCFTracker::init(cv::Rect_<int> const&, cv::Mat) (kcftracker.cpp:121)
==2033==    by 0x73613: AltumTracker::setRoi(cv::Rect_<int>, cv::Mat) (altumtracker.cpp:97)
==2033==    by 0x6B087: selector::setRoiRunTracker(int, int, int, int) (dronose.cpp:88)
==2033==    by 0x694BF: main (dronose.cpp:320)
==2033== 
==2033== Events    : Ir
==2033== Collected : 55834099
==2033== 
==2033== I   refs:      55,834,099
Illegal instruction

The offending lines of code in GCC inline asm look like this:

 "vfma.f32   q7,  q13, q13 \n"
 "vfma.f32   q8,  q14, q14 \n"
 "vfma.f32   q9,  q15, q15 \n"

It's dying on the first one.

I also met this issue.
I'm using Cortex A35 ARM core (ARMv8) and running code built as 32bit.

The instruction unhandled is:
0xF240ACF4
vfma.f32        q13, q8, q10

The full log is as below:
disInstr(arm): unhandled instruction: 0xF240ACF4
                 cond=15(0xF) 27:20=36(0x24) 4:4=1 3:0=4(0x4)
==930== valgrind: Unrecognised instruction at address 0x56772a0.
==930==    at 0x56772A0: ??? (in /usr/lib/libxxxx.so)
==930== Your program just tried to execute an instruction that Valgrind
==930== did not recognise.  There are two possible reasons for this.
==930== 1. Your program has a bug and erroneously jumped to a non-code
==930==    location.  If you are running Memcheck and you just saw a
==930==    warning about a bad jump, it's probably your program's fault.
==930== 2. The instruction is legitimate but Valgrind doesn't handle it,
==930==    i.e. it's Valgrind's fault.  If you think this is the case or
==930==    you are not sure, please let us know and we'll try to fix it.
==930== Either way, Valgrind will now raise a SIGILL signal which will
==930== probably kill your program.
disInstr(arm): unhandled instruction: 0xF240ACF4
                 cond=15(0xF) 27:20=36(0x24) 4:4=1 3:0=4(0x4)
==930== valgrind: Unrecognised instruction at address 0x56772a0.
==930==    at 0x56772A0: ??? (in /usr/lib/libxxxx.so)
==930== Your program just tried to execute an instruction that Valgrind
==930== did not recognise.  There are two possible reasons for this.
==930== 1. Your program has a bug and erroneously jumped to a non-code
==930==    location.  If you are running Memcheck and you just saw a
==930==    warning about a bad jump, it's probably your program's fault.
==930== 2. The instruction is legitimate but Valgrind doesn't handle it,
==930==    i.e. it's Valgrind's fault.  If you think this is the case or
==930==    you are not sure, please let us know and we'll try to fix it.
==930== Either way, Valgrind will now raise a SIGILL signal which will
==930== probably kill your program.