RFC: generating a header using the linker (ASCII, ASCIZ commands)

[Nick Clifton]

Hi Ulf,

>> From the sound of what you have written below it would be
>> easier to use the assembler to create the header 

> One of the problems is time of build.
> The header should contain the time when things are linked together, not when things are compiled.
> 
> Another is that one of the fields is the size of the application which is only known at link time.
> 
> Doing things in the linker seems to be the cleanest way.
> 
> We would probably have the header is in a separate file which is included in the linker script.

If you need to compute information in the header based upon the
actual linked executable then you will not be able to do so from
inside a linker script.  (Well not without modifying the linker,
and I am trying to avoid that).

But - what you can do is post-process the linked file to extract
the information you want, create a separate file containing the
header constructed from this information, and then insert the
header into the executable, without relinking it.  (I am thinking
of objcopy's --add-section command line option here).

Alternatively you could link with a dummy header that is basically
empty and then use a tool like GNU Poke[1] to insert the necessary
bytes and strings afterwards.

[1] http://www.jemarch.net/poke


> Assume you have the following flash sectors.
> 
> * 64kB (65536 bytes)
> * 64kB (65536 bytes)
> * 128kB
> * n x 256kB
> 
> The bootloader resides in the first 64 kB sector and the application starts in the second 64kB sector.
> 
> If the application <= 65536 bytes, the section should be 64kB and should be filled with a FILL value
> 
> If the application is 65540 bytes, the section should be 64kB+128kB and should be filled with a FILL value

Ah yes.  This is a known problem for the linker.  It does not have a mechanism
to distribute section(s) across multiple memory regions, using one until it is full
and then switching to another.

I am sorry, but I do not have an easy workaround for you.  If you are able to try
multiple links, you could start with one that just uses the smallest memory configuration
first, and if that fails move up to bigger configurations, possibly with different
assignments of sections to memory regions afterwards.


> Would you consider adding ielftools to binutils?

I would prefer to leave it as a separate project for now.  I am worried
about bringing in a tool that will only be of use to a very small audience
(maybe just you ?) and having to maintain it.  Of course if you can persuade
more people to request that the sources be integrated then I can take abother
look at the issue...



> Note that if the linker can call an external tool to compute the CRC
> based on the extracted text segment, and insert that into the resulting ELF file.
> then this is superior to running a utility afterwards.

Actually -- there might be a way to do this: A linker plugin.  The linker already
has the architecture to support plugins, and you could create a new one which would
scan the text section, compute a CRC and then insert the value into a header in the
linked image...

Cheers
   Nick