Bug 434283

Summary: disInstr(arm64): unhandled instruction 0xC87FAB5F (LDAXP and STLXP)
Product: [Developer tools] valgrind Reporter: Antonio Ospite <ao2>
Component: memcheckAssignee: ahashmi <assad.hashmi>
Status: RESOLVED DUPLICATE    
Severity: normal CC: ao2, jseward, mark
Priority: NOR    
Version First Reported In: 3.15 SVN   
Target Milestone: ---   
Platform: Android   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Antonio Ospite 2021-03-11 15:00:55 UTC
Hi,

valgrind does not seem to support LDAXP and STLXP on Arm64.


==1782== Memcheck, a memory error detector
==1782== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1782== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info
==1782== Command: /.../my-app
==1782==
...
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xC87FAB5F
disInstr(arm64): 1100'1000 0111'1111 1010'1011 0101'1111
==1782== valgrind: Unrecognised instruction at address 0xb04db58.
==1782==    at 0xB04DB58: ??? (in /system/lib64/libThirdParty.so)
==1782== Your program just tried to execute an instruction that Valgrind
==1782== did not recognise.  There are two possible reasons for this.
==1782== 1. Your program has a bug and erroneously jumped to a non-code
==1782==    location.  If you are running Memcheck and you just saw a
==1782==    warning about a bad jump, it's probably your program's fault.
==1782== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1782==    i.e. it's Valgrind's fault.  If you think this is the case or
==1782==    you are not sure, please let us know and we'll try to fix it.
==1782== Either way, Valgrind will now raise a SIGILL signal which will
==1782== probably kill your program.
Killed


...
  34841c:       c87fab5f        ldaxp   xzr, x10, [x26]
  348420:       c82aa349        stlxp   w10, x9, x8, [x26]
...

Thanks,
Antonio
Comment 1 Julian Seward 2021-11-08 07:16:35 UTC
I'm going to close this as a dup of bug 444399, where there is, now,
a preliminary fix available.

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