Extend ELF to support stack size and priority

[patacongo]

Backgound

ELF is probably the most common binary format in existence. It is used primarily by large desktop systems like Linux but is also used by NuttX. The requirements of a deeply embedded RTOS on a memory limited platform are slightly different.

This issues proposes an extension to the ELF header that would extend the capability of ELF for such deeply embedded systems.

ELF Header

Each ELF binary file begins with an ELF header. See https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html for example.

Nothing in the header depends on the fixed size for the ELF header. So we are free to extend the ELF header with additional fields at the end of the header with any data that we see fit. There are file offsets in the ELF header that determin the location of data in the file. There is no assumption in the file format that any particular thing following the ELF header:

• e_phoff: This member holds the program header table's file offset in bytes. If the file has no program header table, this member holds zero.
• e_shoff: This member holds the section header table's file offset in bytes. If the file has no section header table, this member holds zero.

Addition versioning information be required in the header to indicat that this ELF header includes extensions:

• e_type: This member identifies the object file type.

Which has these defined values:

ET_NONE            0  No file type
ET_REL             1  Relocatable file
ET_EXEC            2  Executable file
ET_DYN             3  Shared object file
ET_CORE            4  Core file
ET_LOOS       0xfe00  Operating system-specific
ET_HIOS       0xfeff  Operating system-specific
ET_LOPROC     0xff00  Processor-specific
ET_HIPROC     0xffff  Processor-specific

I think that 0xfe02 would be a good file type for this extended executable file type. Our code should handle both 0x0002 and 0xfe02. The former woul use default task information, the later would use the extended information that we propose. here.

Stack Size

The first value that needs to included in the extended ELF header is the size of the task's stack to allocate. This is not an issue for high-end desktop systems because the use effectively unlimited stack space, populating the used regions of the stack on demand by mapping pages into place with the MMU.

But memory constrained platforms seldom have an MMU. Instead, a highly tuned, fixed stack size must be provided. Perhaps we would call this e_stacksize and it would need a minimum of around 24-bits to represent.

An option would be to use stack sections that are defined within the ELF format. I have not looked into this as of this writing and this would certainly have more impact on the current ELF design.

Priority

Desktop systems don't typically support real-time behavior (and the ones that do, don't support it well). Precise control of task priority is required in order to support a well-behaved, real-time system that can meet all of its deadlines.

So the second extension to the ELF header would the the priority of the ELF task, e_priority. This would require 8-bits to represent under NuttX.

How to We Build the Binaries?

How do we get the new information into the ELF header? The ELF binaries are built using standard tools and will generate standard ELF headers with no stack or priority information.

I am thinking that a custom tool would be required that would create an new ELF image with:

1. The appropriate e_type in the ELF header,
2. With all offsets in the ELF header adjusted for the increased header size,
3. With the added stack and priority information in the extended ELF header.
4. All data following the ELF header offset appropriately in the file.

[yamt]

i can understand the stack size, but not priority.
IMO, priority belongs to tasks, not binaries.