Bug 435299 - vex amd64->IR: unhandled instruction bytes: 0xF1 0xF 0x86 0x3C 0x0 0x0 0x0 0x48 0xF 0xB7
Summary: vex amd64->IR: unhandled instruction bytes: 0xF1 0xF 0x86 0x3C 0x0 0x0 0x0 0x...
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: callgrind (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: Josef Weidendorfer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-03 08:20 UTC by Jaime Torres
Modified: 2021-06-13 07:57 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Jaime Torres 2021-04-03 08:20:04 UTC 
SUMMARY
Everytime I try to use callgrind with kate/kwrite, the same error:

vex amd64->IR: unhandled instruction bytes: 0xF1 0xF 0x86 0x3C 0x0 0x0 0x0 0x48 0xF 0xB7
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==26062== valgrind: Unrecognised instruction at address 0x11953e05

STEPS TO REPRODUCE
valgrind --tool=callgrind --instr-atstart=no --collect-atstart=yes --collect-jumps=yes --collect-bus=yes --cacheuse=yes /usr/bin/kwrite

==26062== Callgrind, a call-graph generating cache profiler
==26062== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==26062== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==26062== Command: /usr/bin/kwrite
==26062== 
--26062-- warning: L3 cache found, using its data for the LL simulation.
....

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20210330
KDE Plasma Version: 5.21.3
KDE Frameworks Version: 5.80.0
Qt Version: 5.15.2
Kernel Version: 5.11.6-1-default
OS Type: 64-bit
Graphics Platform: X11
Processors: 6 × AMD Phenom(tm) II X6 1100T Processor
Memory: 15.6 GiB of RAM
Graphics Processor: AMD JUNIPER

I guess this started when opensuse changed gcc to versions 9 or greater.
Comment 1 Jaime Torres 2021-06-13 07:57:17 UTC 
Apparently, the dissasembly of 0xF1 0xF 0x86 0x3C 0x0 0x0 0x0 0x48 0xF 0xB7 could be, according to https://onlinedisassembler.com/odaweb/:
f1 icebp
0f863c00000 jbe loc_0000043
48 dec eax
0f byte 0xf
b7 byte 0xb7

where icebp is a replacement for int 01, according to  http://rcollins.org/secrets/opcodes/ICEBP.html