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 2E3DC385B50A for ; Mon, 13 Feb 2023 15:55:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2E3DC385B50A 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 6AA9D12019C; Mon, 13 Feb 2023 16:54:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com; s=default; t=1676303698; bh=7MFEmn6sSUw40i83e4r0e0fZ7TjBf0V+PnYhn3UPWZE=; h=Subject:To:From; b=y80EM7GO8H9mX3eOWIlr8W7O77gNXQR0T+w3LphE6sNSJEyHd6yUJVEAk+XgIgzwO BAodir0EXTPpQZc90hLn9zfYaWVRaHT/Mr3DszS09+D68qWiv/WoeBry4YgAfdEbM/ xnrcp36AvmmnBxdiOjSj5vO63nI0DMP+gReHpco8= 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: Date: Mon, 13 Feb 2023 16:54:58 +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: generating a header using the linker (ASCII, ASCIZ commands) Content-Language: sv-FI To: Jan Beulich Cc: Nick Clifton , binutils@sourceware.org References: <5aa83cea-b8ad-5b36-12ec-6857a5c5541a@redhat.com> <73f54df1-c236-4c4a-c161-85ebe6d6f7b7@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: <167630369870.3742295.6364675385648705468@localhost.localdomain> X-PPP-Vhost: emagii.com X-Spam-Status: No, score=-5.6 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-13 kl. 13:33, skrev Jan Beulich: > On 13.02.2023 12:12, Ulf Samuelsson via Binutils wrote: >> Den 2023-02-13 kl. 11:09, skrev Nick Clifton: >>>> One of the problems was that we wanted to generate a header, >>>> and for various reasons, it was desirable to have the linker generate >>>> the header >>> From the sound of what you have written below it would be >>> easier to use the assembler to create the header and then just >>> include it as another object file when you perform your link. >>> That together with a customised linker script should allow you >>> to achieve what you want without having to add new code to the >>> linker. >> One of the problems is time of build. >> The header should contain the time when things are linked together, not >> when things are compiled. >> >> Another is that one of the fields is the size of the application which >> is only known at link time. >> >> Doing things in the linker seems to be the cleanest way. >> >> We would probably have the header is in a separate file which is >> included in the linker script. > Otherwise I would be wondering if you're not really defining a new binary > format (potentially an extension of an existing one), at which point it > might be best to also treat it as such in binutils / ld. Yes, but each customer has their own header format and they do not want to make changes to binutils. Typically, the image is downloaded and checked by a bootloader which will receive a binary. You also want to be able to download it with a debugger during development. I do not think you need a new binary format for this. Simplifying the creation of the header file is good enough for me. /Ulf > Jan