nuttx
nuttx copied to clipboard
apache
Adding ptrace support to allow for more run time debug support
This is something that I have mulled about a few times. It would really be nice to be able to eventually add a GDB server stub for NuttX to improve application debugging and ptrace would move us a long way in that direction even if only some of the flags were supported.
@patacongo is this something you have ever looked into?
Not me personally, but this was something that David Alessio was always interested in pursuing in the past.
Kgdb would be pretty simple and useful board bring up and FLAT builds. ptrace is only usable for a fully initialized system. I wonder if both could be supported?
In additional to a ptrace system call you need a GDB server. Zephyr has there own: https://github.com/intel/zephyr/blob/master/subsys/debug/gdb_server.c
But maybe that is because they don't support a compatible ptrace(). Do you think it would be possible to use the standard GDB server if a good ptrace were available? Is it too large?
My thought here is more around when I want work on developing an application or exercising a driver interface from userspace usually with the kernel I already have my jlink or something hooked up. Although anything that improves optional debugging features is a win in my book.
I'll keep thinking about it, its not something I am going to do in the short term, but I wanted to make sure I was not reinventing some effort someone had already started.
In additional to a ptrace system call you need a GDB server. Zephyr has there own: https://github.com/intel/zephyr/blob/master/subsys/debug/gdb_server.c
But maybe that is because they don't support a compatible ptrace(). Do you think it would be possible to use the standard GDB server if a good ptrace were available? Is it too large?
The whole server is probably not worth it, you kind find a lot of minimal implementations out there that are no more than a couple hundred lines of code. Its the arch specific logic that tends to make it grow. And if you enable things like non-stopping multithread debugging.
In addition to ptrace we would also need the interface for injecting breakpoints.
I was reading these two articles: https://blog.tartanllama.xyz/writing-a-linux-debugger-setup/ https://blog.0x972.info/?d=2014/11/13/10/40/50-how-does-a-debugger-work
And found them both very informative. This is an area of Linux kernel that I never really explored.
This is an area of Linux kernel that I never really explored.
I have worked with ptrace under Linux before, but not for years. Not since the 2.4-2.6 timeframe.
Just wondering -- what did you decide on including a gdbstub like MRI into nuttx or nuttx-apps? Is the idea unjustified and abandoned? I couldn't find a decisive conclusion searching through the mailing lists.
I played with MRI on a STM32CubeF4 blinky-like project, and the architectural changes look pretty deep (direct USART IRQ handler, half of Cortex-M exceptions handlers, assembly stack peeker, GDB memory XML) so it can't just go into nuttx-apps, also it often needs chip-specific knowledge. It could plug into standard uart drivers for RSP but otherwise is on the level of drivers/note instrumentation w.r.t API depth.
Blackmagic Debug project has a considerable db in its target drivers which allowed them to implement an on-the-fly runtime compose mechanism for memory regions XML for GDB, but there's little introspection in NuttX (apart from linkerscripts) to easily do a similar thing, maybe if only by relying on PROGMEM and linker symbols (which are used for procfs df/free handlers anyway).
While Cortex-M targets are usually easily debug-enabled with just SWD and this is less of a problem for PCB designers to map some special GPIO pads to a debug header, consider RISC-V. For example, WCH CH32V30x don't even implement JTAG (which would use like 5-6 pins but is at least standard), and its SDI is RVSWD, a wildly different beast. Having a RSP gdbstub on its UART would greatly help development on such platforms. Similar point for some i.MX6D SoMs which only have a debugging header as an ordering option.
Mentioning https://github.com/apache/nuttx/pull/7978. ESP32-C3 is a risc-v in-tree target, but it has actual JTAG.
