On Tue, Apr 25, 2023, 3:10 PM Gregory Nutt <spudan...@gmail.com> wrote:
> > 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 is for a kernel build targeting risvc32. > 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. > Similar to debugging Linux kernel modules. > - 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. > I used a similar capability with a different small RTOS a while ago. > 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. > For the kernel build (or MMU support in general) I'd assumed Nuttx would statically link and use the MMU to map the fixed elf section addresses to the pages allocated from the heap. This also helps startup performance as there are no relocations to process. But we're still learning the details of how Nuttx goes together.
