GDB address translation issue when running in RISCV SV39 on QEMU

308 views
Skip to first unread message

james qest

unread,
Nov 25, 2020, 12:48:29 PM11/25/20
to RISC-V SW Dev
Hi All, 
I am trying to run an application in SV39 virtual addressing mode. I have setup the Page Table entries and SATP accordingly. After switching into executing the Virtual Text Address I can see that code executes as expected, but DO NOT see instructions via GDB.

Is there an option which has to be enabled in GDB to view the instructions in Virtual Addr. space ? how can we do source level debug of application which will be loaded and executed in Virtual Memory Address space ? 

My Virtual Text address is at 0x10200000 , the PTEs are setup to map to Physical address 0x18000000

(gdb) p/x $satp

$6 = 0x8000000000010601

(gdb) p/x $mstatus

$7 = 0xaa

(gdb) x /4wx 0x18000ae0            // See the  expected instructions in Physical. addr

0x18000ae0:     0x3aa7b023      0x104027b7      0x4c078793      0x17b7e51c

(gdb) x /4wx 0x10200ae0             // Don't see any instructions in Virtual addr

0x10200ae0:       0x00000000      0x00000000      0x00000000      0x00000000

(gdb) si                                       // Able to execute code, but don't see the instructions ??

0x0000000010200ae0 

(gdb) si

0x0000000010200ae4 

(gdb) si                    // How to do source debug of an application using  Virtual mem ?

0x0000000010200ae8 

(gdb) si

0x0000000010200aec

Note : 
I have used " maintenance packet Qqemu.PhyMemMode:1 " to switch to Phy memory mode to view the memory. Is there some option to view instruction addresses in Virtual Addr. space ? 

Pls let me know, Thanks 

J

Jim Wilson

unread,
Nov 25, 2020, 1:31:45 PM11/25/20
to james qest, RISC-V SW Dev
On Wed, Nov 25, 2020 at 9:48 AM james qest <questj...@gmail.com> wrote:
Hi All, 
I am trying to run an application in SV39 virtual addressing mode. I have setup the Page Table entries and SATP accordingly. After switching into executing the Virtual Text Address I can see that code executes as expected, but DO NOT see instructions via GDB.

You can find gdb experts on the FSF gdb mailing lists.  You might try asking there.  But as far as I know ...

gdb doesn't know anything about page tables.  It only knows addresses.  If you are connecting gdb to a system mode qemu, then gdb will only have access to physical addresses.  This is really only useful for debugging the kernel.

If you are booting linux on qemu, and then running an application on linux, then you can just run gdb as an user program under linux and attach to your application.  Or use gdb to start your application.

Alternatively, assuming you set up a network connection to your linux under qemu, you can run gdbserver as a user program, and then use gdb on the host to connect over the network to the gdbserver running on your linux running on qemu, and then use gdbserver to connect to the application you wan to debug.

Gdb as an app will use the ptrace system call to get access to the virtual memory of the process it is debugging.  Similarly gdbserver as an app can use ptrace.  But a gdb on the host can not call the target kernel's ptrace system call, and hence can't get access to the target application's virtual memory.

Jim

Sober Liu

unread,
Nov 25, 2020, 7:29:20 PM11/25/20
to Jim Wilson, james qest, RISC-V SW Dev

+1. I think OS need to be invoked for virtual address debug.

 

From: Jim Wilson <ji...@sifive.com>
Sent: 20201126 2:31
To: james qest <questj...@gmail.com>
Cc: RISC-V SW Dev <sw-...@groups.riscv.org>
Subject: Re: [sw-dev] GDB address translation issue when running in RISCV SV39 on QEMU

 

External email: Use caution opening links or attachments

 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAFyWVab9Gg%3DdRN5OVmrhG%2BZqf4iTR6ZOFQXU7zNEp7_aRj1CVQ%40mail.gmail.com.

Reply all
Reply to author
Forward
0 new messages