[RFC v0 0/1] Add support for CRC64 generation in linker
Fangrui Song
i@maskray.me
Mon Mar 6 07:50:21 GMT 2023
On Fri, Feb 17, 2023 at 4:03 AM Ulf Samuelsson <binutils@emagii.com> wrote:
>
>
> 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.
Hi Ulf, I think a natural question from other binutils contributors
is: why is the CRC-64 feature so special that it deserves several
keywords dedicated for it in the linker script language.
You can place placeholder content into the CRC-64 section (say, it is
.crc64), compute its value with a post-link program, then update the
content with
objcopy --update-section .crc64=.... exe
If objcopy --update-section somehow doesn't achieve your goal, it may
be worth a feature request or bug, since the operation is generic and
useful for a large number of users, not just your CRC-64 customers.
> 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.
I am unsure how a linker script extension is more convenient than
using the existing functionality plus a CRC64 calculator and objcopy.
The linker script extension appears to add a lot of code to the linker
script language, which is already quite challenging to maintain.
If you distribute such object files with CRC64, I don't think it harms
debuggability.
> >
> >
> >> 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
>
>
More information about the Binutils
mailing list