Hi! I had no problems debugging NuttX with protected mode on ESP32-S3 (esp32s3-devkit:knsh).
After launching OpenOCD (https://github.com/espressif/openocd-esp32) with `-c 'set ESP_RTOS none' -c "set ESP_FLASH_SIZE 0"`, just load the userspace's symbols with `add-symbol-file` (with the address of the `.text` region, that you can check with `objdump`, for instance) xtensa-esp32s3-elf-gdb -ex "target extended-remote :3333" -ex "symbol-file nuttx" -ex "add-symbol-file nuttx_user.elf 0x42090000" -ex "set remote hardware-watchpoint-limit 2" -ex "mon reset halt" -ex "flushregs" -ex "set print pretty" --tui It works as expected on ESP32-S3. Best regards, Em ter., 25 de abr. de 2023 às 09:28, Gregory Nutt <spudan...@gmail.com> escreveu: > > >>> 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. > > It was late last night when I responded. In the clear light of morning > I can see that my "justification" is lame and probably wrong. > > The REAL reason that the ELF modules work as they do is because they > were designed to work in the FLAT build with all physical addressing. > It is used with the KERNEL build because it works there too. > > That can't be changed only for the KERNEL build, but there could be a > fully linked ELF binary just for the KERNEL build. That should be too > difficult. Things that occur to me are: > > * There are no tools for building such as executable. It would > probably have to be implemented within a Makefile as is the current > ELF module build. > * There are no shared libraries so everything .. libc, syscalls, etc. > ... has to be statically linked. I think that is true of the > existing ELF modules in the KERNEL build anyway. > * Some minor tweaks to crt0 might be necessary (?). > > -- Tiago Medicci Serrano Embedded Software Engineer MSc Electronics/Microelectronics m: +55 (19) 981403886 <+55+(19)+981403886> e: tiago.medi...@gmail.com a: Campinas, Brazil Follow me: <https://www.linkedin.com/in/tiago-serrano-924458b6> <https://github.com/tmedicci>
