box64 icon indicating copy to clipboard operation
box64 copied to clipboard

[GDBJIT] Unable to obtain function backtrace

Open devarajabc opened this issue 2 months ago • 1 comments

I followed the documentation for using GDBJIT, but I couldn’t obtain the function call stack.

GDB can display the corresponding x86_64 and RV64 instructions correctly; however, the backtrace (bt) fails to resolve properly.

I’d like to know how to retrieve the backtrace of a function to understand the chaining mechanism of dynamic blocks — for example, how a dynamic block calls rv64_next to link to next block.

Steps to Reproduce

  1. Compile Box64 with -DGDBJIT=ON
  2. Run with export BOX64_DYNAREC_GDBJIT=2
  3. In GDB (gdb) jit-reader-load /usr/local/lib/libbox64gdbjitreader.so

Observed Behavior

GDB can display x86_64 instructions correctly:

[BOX64] Using native(wrapped) libresolv.so.2
[BOX64] Using native(wrapped) librt.so.1
[BOX64] Using native(wrapped) libbsd.so.0
^C
Program received signal SIGINT, Interrupt.
0x0000003ff73eb570 in 11f0 () at /tmp/box64gdbjit-u9cwUA.S:6
warning: Source file is more recent than executable.
6	SUB Gd, Ed

The generated .S file includes the expected info (as in PR #2179):

 cat /tmp/box64gdbjit-u9cwUA.S
; 0: 0 opcodes, barrier=0 state=0/0(0), set=0/0, use=0, need=0/0, fuse=0/0, sm=0(0/0), sew@entry=7, sew@exit=7, last_ip=0x1000011f0
NOP / ENDBR32 / ENDBR64
; 1: 1 opcodes, barrier=0 state=0/0(0), set=0/0, use=0, need=0/0, fuse=0/1, sm=0(0/0), sew@entry=7, sew@exit=7, pred=0, last_ip=0x1000011f0
MOV Gd, Ed
; 2: 9 opcodes, barrier=0 state=3/0(0), set=3F/80, use=0, need=0/80, fuse=0/0, sm=0(0/0), sew@entry=7, sew@exit=7, pred=1, last_ip=0x1000011f0
SUB Gd, Ed
; 3: 25 opcodes, barrier=0 state=0/3(0), set=0/0, use=80, need=80/0, fuse=0/0, sm=0(0/0), sew@entry=7, sew@exit=7, pred=2, last_ip=0x1000011f0
RET

Disassembly shows RV64 instructions as expected:

(gdb) disassemble 
Dump of assembler code for function 11f0:
   0x0000003ff73eb560 <+0>:	fsd	fs0,104(a2)
   0x0000003ff73eb562 <+2>:	sd	a5,424(sp)
   0x0000003ff73eb564 <+4>:	.insn	8, 0x000568030000003f
   0x0000003ff73eb56c <+12>:	lwu	t1,0(a1)
=> 0x0000003ff73eb570 <+16>:	sw	a6,1112(s9)
   0x0000003ff73eb574 <+20>:	sw	t1,1120(s9)
   0x0000003ff73eb578 <+24>:	li	t3,50
   0x0000003ff73eb57c <+28>:	sw	t3,1108(s9)
   0x0000003ff73eb580 <+32>:	subw	a6,a6,t1
   0x0000003ff73eb584 <+36>:	sw	a6,1128(s9)

However, backtrace (bt) fails to resolve properly:

(gdb) bt
#0  0x0000003ff73eb570 in 11f0 () at /tmp/box64gdbjit-u9cwUA.S:6
Backtrace stopped: frame did not save the PC

The same issue occurs when breaking at rv64_next:

Breakpoint 1, rv64_next () at /root/box64/src/dynarec/rv64/rv64_next.S:19
19	    addi    sp,  sp,  -(8 * 10)
(gdb) bt
#0  rv64_next () at /root/box64/src/dynarec/rv64/rv64_next.S:19
Backtrace stopped: frame did not save the PC

Environment

Same config as in issue https://github.com/ptitSeb/box64/issues/2710 but with the new version of box64

Thanks.

devarajabc avatar Oct 11 '25 10:10 devarajabc

I don't think the backtrace issue is linked to gdbjit in that case, but more to the fast that the dynarec doesn't setup the link register in a sane way for backtrace to actualy work. This need to be seen if, maybe at least the prolog, can create a corect frame for libc backtrace to function correctly.

ptitSeb avatar Oct 17 '25 14:10 ptitSeb