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 C6B513857438 for ; Thu, 16 Feb 2023 22:37:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6B513857438 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 30A26120145; Thu, 16 Feb 2023 23:37:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com; s=default; t=1676587067; bh=IrwE7r4YYW8Uqo2vJNm7L+/W1rjrTANAM/zGXFQ9Ub4=; h=Subject:To:From; b=JLuLJ/a5uEWz6ok/ah6/06o1roA01QgjjYdlkiYpANTU94w7XVV6Hmi3ycBpvJeQp fykPnh39UsvonSfyXKIW3YRmzegp1Q0Li7XvtcZOR1UT9xC8GIP5fVBtvgRehDJYYg PexMehiDkdhTCbfJWg8tRa8z4S+wz8NDgPr8shbc= 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: <8c80d58c-8c43-90c9-9d0b-9a5de91c16ed@emagii.com> Date: Thu, 16 Feb 2023 23:37:46 +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: Fangrui Song Cc: binutils@sourceware.org, nickc@redhat.com References: <20230216204006.1977-1-binutils@emagii.com> From: Ulf Samuelsson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <167658706746.3920212.8187096136699545367@localhost.localdomain> X-PPP-Vhost: emagii.com X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,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-16 kl. 22:30, skrev Fangrui Song: > On Thu, Feb 16, 2023 at 12:40 PM Ulf Samuelsson via Binutils > 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