From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emagii.se (www.emagii.com [185.133.207.17]) by sourceware.org (Postfix) with ESMTPS id BC507385B52F for ; Fri, 17 Feb 2023 12:03:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC507385B52F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=emagii.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emagii.com Received: from [10.175.196.145] (84-55-68-216.customers.ownit.se [84.55.68.216]) by emagii.se (Postfix) with ESMTPSA id B3987120153; Fri, 17 Feb 2023 13:03:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com; s=default; t=1676635413; bh=r0ZXVZX+82djRjo4w3xDeFNQCPYtXuoeZHp2DRGZfg4=; h=Subject:To:From; b=0Nqh5xNsCNNC/s0o/iYQN+HhjXYdjhAS20KGUH3TVnPvJaY2pz3yGARvyxZNsZ0s/ A7gh09z2LDWgQIHqmSHVknKyov5R8tRO/a3xOqpIu54mvNtC8z0QsnUMjbr7XXtU/0 wI1iESoAPOViUNvQLefq3Nniql/a9chJJ1gfEVFk= Authentication-Results: emagii.beebytevps.io; spf=pass (sender IP is 84.55.68.216) smtp.mailfrom=binutils@emagii.com smtp.helo=[10.175.196.145] Received-SPF: pass (emagii.beebytevps.io: connection is authenticated) Message-ID: <8c16e149-2117-56e1-61bf-a499f05a8fb9@emagii.com> Date: Fri, 17 Feb 2023 13:03:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [RFC v0 0/1] Add support for CRC64 generation in linker Content-Language: sv-FI To: Nick Clifton , Fangrui Song Cc: binutils@sourceware.org References: <20230216204006.1977-1-binutils@emagii.com> <8c80d58c-8c43-90c9-9d0b-9a5de91c16ed@emagii.com> <328005c0-a162-764e-47ba-036dce0ecbe4@redhat.com> From: Ulf Samuelsson In-Reply-To: <328005c0-a162-764e-47ba-036dce0ecbe4@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <167663541147.4039573.7732515756119983401@localhost.localdomain> X-PPP-Vhost: emagii.com X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_FAIL,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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