Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Ulf Samuelsson <binutils@emagii.com>]

Den 2023-02-17 kl. 12:11, skrev Nick Clifton:
> Hi Ulf,
>
>>> Hi Ulf, can you state why a built-in support of ld is needed? If you
>>> want to embed a checksum, you can use Output Section Data to reserve a
>>> few bytes in the output, then use a post-link tool to compute the
>>> checksum and rewrite the reserved bytes.
>
>> In my experience, the post link tools usually work on the binary data 
>> and not the ELF file.
>
> The objcopy program can do most of this for you though.  For example:
>
>   % objcopy --dump-section .text=contents-of-text a.out
>   % crc32 contents-of-text > crc32-of-text
>   % objcopy --add-section .crc32=crc32-of-text a.out
>   % readelf -x.crc32 a.out
>   Hex dump of section '.crc32':
>     0x00000000 32323064 37636339 0a                220d7cc9.
>
> In this example the crc32 is stored as ascii text, but I am sure that
> you can find a version of the crc32 program that generates binary output.

The crc32 generates a 32-bit CRC. Modern microcontrollers require a 
64-bit CRC.

The second problem is: where is the .crc32 section and its contents?
The program needs to access the contents, but it is already linked.
The typical use is a header in front of the program, and the header
is part of the ".text" area.
Can you explain how this would work?

>
>
>> Another thing is that the post-link tools I have seen are typically 
>> poorly maintained.
>
> ...and so you want to move that maintainership burden onto us, yes ?

The problem with the post-link tools is that they are hard wired to work on
special use cased.
Example of problems

* CRC is fixed to be at a certain address

* CRC table is fixed to be at a certain address.

* Works on binaries and not on ELF files

* You have to have one postprocessor for each file format.

None of these problems affect the linker since it is agnostic on the 
file format
as long as there is a ".text" section.

The CRC calculation has been stable on www.libcrc.com for 7 years.
There is no reason for the CRC calculation to change.
The only chance I can see is a different polynom, but that is already 
supported.

The biggest problem is of course that it slows down the debugging
because you cannot download from an ELF file - it lacks the CRC.

>
>
>> Adding a post-link step seems like a kludge if the linker can provide 
>> the CRC inside the ELF file.
>
> But it also keeps things simple.  No new code in the linker = no new
> bugs in the linker.  Solving a problem using existing tools = no need
> for new versions of the linker when the already existing versions will
> work just fine.

The problem is that the existing versions *barely* work.
Every company have to write their own solution.
It does not support source level debugging.

Supporting it in the linker makes for a much cleaner solution.

>
> Cheers
>   Nick
>
Best Regards

Ulf Samuelsson