Elf representation in HEX

0
votes

I am working on understanding some ground concepts in embedded Systems. My question is similar to understand hexedit of an elf . In order to burn compiler output to ROM, the .out file is converted to HEX (say intel-hex). I wonder how the following informations are preserved in HEX format:

  1. Section header
  2. Symbol tables, debug symbols, linker symbols etc.
  3. Elf header.
  4. If these are preserved in HEX file, how they can be read from hex file?
  5. A bit out question but how the microcontroller on boot knows where .data .bss etc. exists in HEX and to be coppied to RAM?
2
embeddedhexmicrocontrollerelfhexdump
You're mixing up two very different things. The 'hexedit of an ELF' would just be the binary contents of the ELF file rendered as hexadecimal bytes for human viewing. But an Intel Hex file is typically a representation of what goes into a programmable memory. - Chris Stratton

2 Answers

2
votes

None of that is preserved. A HEX file only contains the raw program and data. https://en.wikipedia.org/wiki/Intel_HEX

The microcontroller does not know where .data and .bss are located - it doesn't even know that they exist. The start-up code which is executed before main() is called contains the start addresses of those sections - the addresses are hard-coded into the program. This start-up code will be in the HEX file like everything else.

2
votes

The elements in points 1 to 3 are not included in the raw binary since they serve no purpose in the application; rather they are used by the linker and the debugger on the development host, and are unnecessary for program execution where all you need is the byte values and the address to write them to, which is more or less all the hex file contains (may also contain a start address record).

Systems that have dynamic linking or self-hosted debug capabilities (such as VxWorks for example) use the object file file.

With respect to point 5, the microcontroller does not need to know; the linker uses that information when resolving absolute and relative addresses in the object code. Once filly resolved (linked), the addresses are embedded in the code directly. Again where dynamic loading/linking is used the object file meta-data is required and such systems do not normally load a raw hex file or binary.