This is old and does not specifically address kernel mode, but I think most of
the debug tips do apply in kernel mode too. The load address is a constant for
kernel ELF modules so at least that part doesn't apply. But the rest probably
does.
On 1/9/2024 7:20 PM, yfliu2008 wrote:
Alan,
Thanks a lot for your warm replies.
These apps are built with kernel mode export libraries, their entrances are all
"main" as they each run in their user address spaces.
So when gdb connected with QEMU, command "break qemu_rv_start" can work but "break
main" simply got function not defined even though I did "load ../apps/bin/init". It seems to me that
current gdb session is bound to the kernel ELF, not to the apps ELF.
Regards,
yf
Original
From:"Alan C. Assis"< acas...@gmail.com >;
Date:2024/1/10 8:11
To:"dev"< dev@nuttx.apache.org >;
Subject:Re: debugging user app crashes
Hi Yf Liu,
I don't know if this minidump server works on 64-bit and with QEMU, but
about the other question how to setup breakpoint in the NSH user space
program, just set the break point to the nsh_main if you want to debug the
NSH itself or set it to program_main to put the breakpoint to some user
program called from NSH. For example: setting it to hello_main will cause
the GDB to stop at hello_main when you type "nsh> hello" and press enter.
BR,
Alan
On Mon, Jan 8, 2024 at 9:13 PM yfliu2008 wrote:
> Dear community,
>
>
>
>
> I have NSH command crashes within qemu-system-riscv64 using a testing
> rv-virt/knsh configuration, I wonder what tools can I use to find the crash
> stack?
>
>
>
>
> I have feed console crash.log to minidumpserver.py as per this guide:
> https://nuttx.apache.org/docs/12.3.0/guides/minidumpserver.htm, but
> it seems the tool might not support 64bit yet?
>
>
>
>
> I've tried gdb connection with qemu-system-riscv64 as per this
> guide: https://nuttx.apache.org/docs/12.3.0/guides/gdbwithpython.html,
> but I don't know how to set a break point in the user space NSH program.
>
>
>
>
> Can anyone give me a pointer?
>
>
>
>
> Regards,
>
> yf
