You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/05/18 14:36:58 UTC

[GitHub] [incubator-nuttx] patacongo opened a new issue #1065: Extend ELF to support stack size and priority

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:
users@infra.apache.org



[GitHub] [incubator-nuttx] yamt commented on issue #1065: Extend ELF to support stack size and priority

Posted by GitBox <gi...@apache.org>.
yamt commented on issue #1065:
URL: https://github.com/apache/incubator-nuttx/issues/1065#issuecomment-632512939


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


----------------------------------------------------------------
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:
users@infra.apache.org