On 4/24/2023 7:27 PM, Andrew Dennison wrote:
Are there any examples of a gdb setup to debug a userspace process? One key
issue is to setup the section offsets to match the final application
location once it has been loaded.
You don't describe your build, so I only give you a general answer.
This does not specifically address what you need to do, but might be
helpful:
https://cwiki.apache.org/confluence/display/NUTTX/Debugging+ELF+Loadable+Modules
I think the basics would be the same for all builds.
- You need to be able to stop the ELF module (FLAT or KERNEL build) or
in FLASH program (PROTECTED build).
- Then you can just add the symbol table of the ELF module )or user
space) to the debugger.
I was actually quite surprised that Nuttx applications are still partially
linked with a protected build and that all sections overlap (start at 0) in
the elf file. I had expected the application would be fully linked to
virtual addresses as per linux and another RTOS I used previously. Is this
something that can be changed relatively easily, or are there some
significant challenges?
That would effect the build logic and the binary loader. The effort
would probably be significant.
Are you doing a kernel build? In that case, all applications are
partially linked ELF modules as you describe. Linux positions .bss,
.data, immediately after .text in the virtual address space. Heap and
thread stacks and other things are after that. So Linux applications can
be fully linked.
NuttX allocates everything from the heap when the module is loaded. So
the application must be fully relocatable and address fix-ups are
needed. So the ELF module is a partially linked relocatable ELF file.
