Bug 476895 - [aarch64] unhandled instruction 0xF8BFC273
Summary: [aarch64] unhandled instruction 0xF8BFC273
Status: RESOLVED DUPLICATE of bug 476465
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (other bugs)
Version First Reported In: 3.22 GIT
Platform: Other Other
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-12 20:55 UTC by Romain Geissler
Modified: 2023-11-15 13:27 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Romain Geissler 2023-11-12 20:55:22 UTC
Hi,

While running the test suite of json-c (https://github.com/json-c/json-c) on different toolchain, with the most recent of it I hit in valgrind an unhandled instruction. It seems the test suite of json-c will run the test under valgrind by default if valgrind is installed.

I use valgrind 3.22, and I backported this commit to make sure it's not a dotprod variant: https://sourceware.org/git/?p=valgrind.git;a=commit;h=f42b9a434e12bc14ec821183a69b86e91da0577c

With a toolchain based on gcc 9 or 11, it's ok. With a toolchain based on gcc 13 I git the issue. This gcc was configured with these flags managing instructions: --with-arch-64=armv8.2-a+fp16+rcpc+dotprod+crypto --with-tune-64=neoverse-n1

In the valgrind log (for any tests), I can see:

ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xF8BFC273
disInstr(arm64): 1111'1000 1011'1111 1100'0010 0111'0011

I am not sure which kind of instruction this is :(

I guess from the binary opcode dump someone who knows the aarch64 assembly can "guess it".

Cheers,
Romain
Comment 1 Mark Wielaard 2023-11-15 10:23:34 UTC
Have you tried running under vgdb https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
so you can disassemble from gdb?
Or use objdump -d to see which instruction this is?
Comment 2 Romain Geissler 2023-11-15 11:35:50 UTC
Ah I am totally dumb, you are right !

Sorry, will do that ASAP !
Comment 3 Romain Geissler 2023-11-15 13:25:12 UTC
So after running with gdb, indeed the issue comes from a dynamic linker function (I am using glibc's ld.so):

Dump of assembler code for function _dl_name_match_p:
   0x0000000004009ba0 <+0>:     stp     x29, x30, [sp, #-32]!
   0x0000000004009ba4 <+4>:     mov     x29, sp
   0x0000000004009ba8 <+8>:     stp     x19, x20, [sp, #16]
   0x0000000004009bac <+12>:    mov     x19, x1
   0x0000000004009bb0 <+16>:    mov     x20, x0
   0x0000000004009bb4 <+20>:    ldr     x1, [x1, #8]
   0x0000000004009bb8 <+24>:    bl      0x401b700 <strcmp>
   0x0000000004009bbc <+28>:    cbz     w0, 0x4009be8 <_dl_name_match_p+72>
   0x0000000004009bc0 <+32>:    ldr     x19, [x19, #56]
   0x0000000004009bc4 <+36>:    cbnz    x19, 0x4009bd4 <_dl_name_match_p+52>
   0x0000000004009bc8 <+40>:    b       0x4009bf8 <_dl_name_match_p+88>
=> 0x0000000004009bcc <+44>:    ldapr   x19, [x19]

So this bug report is a duplicate of #476465
Comment 4 Romain Geissler 2023-11-15 13:25:43 UTC
Duplicate of https://bugs.kde.org/show_bug.cgi?id=476465
Comment 5 Romain Geissler 2023-11-15 13:27:42 UTC

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