patacongo opened a new issue #1065: URL: https://github.com/apache/incubator-nuttx/issues/1065
## 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 follow 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. ## Stack Size The first value that needs to included in the extended ELF header is the size of the 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. ## Priority Desktop systems don't typicall 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. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
