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

[Ulf Samuelsson <binutils@emagii.com>]

Den 2023-02-16 kl. 22:30, skrev Fangrui Song:
> On Thu, Feb 16, 2023 at 12:40 PM Ulf Samuelsson via Binutils
> <binutils@sourceware.org> wrote:
>> Cleaned up attempt to generate CRC64.
>>
>>
>> Added code in lang_end() to calculate the CRC.
>> So far, I can retrieve the location of the CRC
>> and the start and end for the area.
>> I can fetch the .text segment as an asection but
>>
>>    if ( bfd_get_section_contents (link_info.output_bfd,
>>            ts,
>>            text_section,
>>            0,
>>            ts->size))
>>
>> fails...
>>
>> The patchset should contain the LICENSE and the testsuite
>> but git-send-email does not like if I send 8 patches.
>> Sending 6 patches is OK for some reason...
>>
>> [PATCH v0 1/6] CRC64 header
>> [PATCH v0 2/6] ldlang.h: CRC64
>> [PATCH v0 3/6] ldlex.l: CRC64
>> [PATCH v0 4/6] ldgram.y: CRC64
>> [PATCH v0 5/6] ldlang.c: CRC64
>> [PATCH v0 6/6] ldlang.c: Try to get the .text section for checking
>>
> 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.

Yes, this is what I have been doing so far, and I am not happy about it.

In my experience, the post link tools usually work on the binary data 
and not the ELF file.
The IAR ielftool that I ported is an exception, but it is not 100% 
compatible with the result of the GNU linker.

That means that you cannot load the ELF file into a debugger and run,
because you do not have the CRC in the ELF file, only in the 
binary/hex-file.

Another thing is that the post-link tools I have seen are typically 
poorly maintained.

Adding a post-link step seems like a kludge if the linker can provide 
the CRC inside the ELF file.

> I am asking because I am unsure whether this feature is generic enough
> to meet a majority of future users' needs. We can reasonably expect
> that other users may want to use different message digest
> algorithms...

The feature allows a CRC-64 to be generated using either ECMA, ISO or a 
user defined polynom.
This means that you cannot make a more generic CRC-64.

The only projects I can see that would need anything else are 8 bit 
micros with a few kB of flash.
They could use a CRC-32 and may trade off speed for code size using a 
non-table driven version.

Adding this functionality does not mean that a user have to use it.
They can continue to use a post-link tool to create CRC64 or any other CRC.
If they want something else, they can do that as well.

For those that do want CRC64, this simplifes things a lot.

> Cheers

Best Regards
Ulf Samuelsson