Bug 470489 - vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0xFD 0x28 0x7C 0xE0 0x48 0x8D 0x90 0x0
Summary: vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0xFD 0x28 0x7C 0xE0 0x4...
Status: RESOLVED DUPLICATE of bug 383010
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.16.0
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-31 13:55 UTC by toitran4195
Modified: 2024-02-25 02:09 UTC (History)
2 users (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 toitran4195 2023-05-31 13:55:17 UTC
SUMMARY
Could not start binary under valgrind and got the "Unrecognised instruction" error
==7844== Memcheck, a memory error detector
==7844== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7844== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==7844== Command: ./gnb_cu_cp
==7844== Parent PID: 7629
==7844==
vex amd64->IR: unhandled instruction bytes: 0x62 0xF2 0xFD 0x28 0x7C 0xE0 0x48 0x8D 0x90 0x0
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
==7844== valgrind: Unrecognised instruction at address 0x7bf277.
==7844==    at 0x7BF277: rte_power_ethdev_pmgmt_init (in /home/automation/CUREPO_CP/gNB_CU/build/cucp_bin/bin/gnb_cu_cp)
==7844==    by 0x1BE457C: __libc_csu_init (in /home/automation/CUREPO_CP/gNB_CU/build/cucp_bin/bin/gnb_cu_cp)
==7844==    by 0xA124C7D: (below main) (in /usr/lib64/libc-2.28.so)
==7844== Your program just tried to execute an instruction that Valgrind
==7844== did not recognise.  There are two possible reasons for this.
==7844== 1. Your program has a bug and erroneously jumped to a non-code
==7844==    location.  If you are running Memcheck and you just saw a
==7844==    warning about a bad jump, it's probably your program's fault.
==7844== 2. The instruction is legitimate but Valgrind doesn't handle it,
==7844==    i.e. it's Valgrind's fault.  If you think this is the case or
==7844==    you are not sure, please let us know and we'll try to fix it.
==7844== Either way, Valgrind will now raise a SIGILL signal which will
==7844== probably kill your program.
==7844==
==7844== Process terminating with default action of signal 4 (SIGILL)
==7844==  Illegal opcode at address 0x7BF277
==7844==    at 0x7BF277: rte_power_ethdev_pmgmt_init (in /home/automation/CUREPO_CP/gNB_CU/build/cucp_bin/bin/gnb_cu_cp)
==7844==    by 0x1BE457C: __libc_csu_init (in /home/automation/CUREPO_CP/gNB_CU/build/cucp_bin/bin/gnb_cu_cp)
==7844==    by 0xA124C7D: (below main) (in /usr/lib64/libc-2.28.so) 

objdump -d gnb_cu_cp |grep "62 f2 fd 28 7c e0"
7bf277:       62 f2 fd 28 7c e0       vpbroadcastq %rax,%ymm4


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: rhel 8.6

ADDITIONAL INFORMATION
The binary can start successfully without valgrind. I tried to use latest valgrind version 3.21 but facing the same issue
Comment 1 Tom Hughes 2023-05-31 14:43:25 UTC
That's an AVX-512 instruction, or an EVEX prefix at least which amount to the same thing from our point of view.

*** This bug has been marked as a duplicate of bug 383010 ***