Bug 476895

Summary:	[aarch64] unhandled instruction 0xF8BFC273
Product:	[Developer tools] valgrind	Reporter:	Romain Geissler <romain.geissler>
Component:	general	Assignee:	Julian Seward <jseward>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	mark
Priority:	NOR
Version First Reported In:	3.22 GIT
Target Milestone:	---
Platform:	Other
OS:	Other
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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 ***