>>> 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 (?).
