From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 69E52382E6AE for ; Mon, 13 Feb 2023 14:11:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 69E52382E6AE Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676297483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qfJBuMQo+hD2od6Zjm0eY3hT32vFrwgVo8uHqXguOok=; b=ORsUaPOt+G9nIBEQ6X1yqkIgZ1aAvTLrP6xHEAG3jctBuTQ9fP5aq7NhO/MpQX6lo90a3u 2MfLmPDOgMAYgq//ybu6r4j9LCumKOhu/zBrhB941MgX9mrV3xYdvaD6WfqjN7000lKxpI M4fRjNsy2q9lAlEl0825Qp0qUr7CqVE= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-241-B0H3UOd1M7C9eOZHsH6OBg-1; Mon, 13 Feb 2023 09:11:22 -0500 X-MC-Unique: B0H3UOd1M7C9eOZHsH6OBg-1 Received: by mail-qk1-f197.google.com with SMTP id a198-20020ae9e8cf000000b007259083a3c8so7503715qkg.7 for ; Mon, 13 Feb 2023 06:11:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qfJBuMQo+hD2od6Zjm0eY3hT32vFrwgVo8uHqXguOok=; b=rB+WUxQXu3iuRmZTatUf623/wTnFn79Gyhc07yPZ9YaVbN14BQLax8ZsKs/UF0EnMm dp1kFZ8F/JwHpJPNRd50NRb0+P7aNLuZDD6AwN9A1VRPjy0QzP4jKZSyMdmeX48zvynK KvGIZDuSLLbDZbxeOqN7+Y40gXvOt5OvVC5CMDhAtSwSpolLt5s92n6Bw3JwUsC8+sQi bEHog5MQGVzYXgcdZS6rjCGk4vPBL/IPhQahg5s3ZXZAuIzKXsAAybkjta9sa+LxYClg hbQHN+4ke4b86mTx8ewv7aXo8n8ABlLu4f4jx4dD5G4n5ebziAhsf25+JGFwCurhFCy6 xPRw== X-Gm-Message-State: AO0yUKWkXrddAgr6mZPAEU0TXR1QHNJAtb6AFRb5rKE1SkSCvwiqcWaT xTwek2Sqai1bP8VHJIP74MVuTTnN/B6Z1g14ovJeHJp/kD9iXzR/JOLkoDbLsFCmWynWV4ZsqLW SrP+8bgxYWo69kJnZwMAsiSo= X-Received: by 2002:ac8:7dc7:0:b0:3ba:1113:751a with SMTP id c7-20020ac87dc7000000b003ba1113751amr42152944qte.67.1676297481395; Mon, 13 Feb 2023 06:11:21 -0800 (PST) X-Google-Smtp-Source: AK7set+VJnSkHnectS6en8FeQnRZrPtndWKvu2VB1N1uSAZVSYPEs03IhOz8k7qwuS6lhUeFp2w+Yw== X-Received: by 2002:ac8:7dc7:0:b0:3ba:1113:751a with SMTP id c7-20020ac87dc7000000b003ba1113751amr42152924qte.67.1676297481169; Mon, 13 Feb 2023 06:11:21 -0800 (PST) Received: from [192.168.1.18] ([79.123.83.169]) by smtp.gmail.com with ESMTPSA id 2-20020a05620a040200b006fbb4b98a25sm9807503qkp.109.2023.02.13.06.11.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Feb 2023 06:11:20 -0800 (PST) Message-ID: <7216fa28-4769-5bd2-a508-bf71184727fd@redhat.com> Date: Mon, 13 Feb 2023 14:11:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: Ulf Samuelsson , binutils@sourceware.org References: <5aa83cea-b8ad-5b36-12ec-6857a5c5541a@redhat.com> <73f54df1-c236-4c4a-c161-85ebe6d6f7b7@emagii.com> From: Nick Clifton Subject: Re: RFC: generating a header using the linker (ASCII, ASCIZ commands) In-Reply-To: <73f54df1-c236-4c4a-c161-85ebe6d6f7b7@emagii.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: Hi Ulf, >> From the sound of what you have written below it would be >> easier to use the assembler to create the header > 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. If you need to compute information in the header based upon the actual linked executable then you will not be able to do so from inside a linker script. (Well not without modifying the linker, and I am trying to avoid that). But - what you can do is post-process the linked file to extract the information you want, create a separate file containing the header constructed from this information, and then insert the header into the executable, without relinking it. (I am thinking of objcopy's --add-section command line option here). Alternatively you could link with a dummy header that is basically empty and then use a tool like GNU Poke[1] to insert the necessary bytes and strings afterwards. [1] http://www.jemarch.net/poke > Assume you have the following flash sectors. > > * 64kB (65536 bytes) > * 64kB (65536 bytes) > * 128kB > * n x 256kB > > The bootloader resides in the first 64 kB sector and the application starts in the second 64kB sector. > > If the application <= 65536 bytes, the section should be 64kB and should be filled with a FILL value > > If the application is 65540 bytes, the section should be 64kB+128kB and should be filled with a FILL value Ah yes. This is a known problem for the linker. It does not have a mechanism to distribute section(s) across multiple memory regions, using one until it is full and then switching to another. I am sorry, but I do not have an easy workaround for you. If you are able to try multiple links, you could start with one that just uses the smallest memory configuration first, and if that fails move up to bigger configurations, possibly with different assignments of sections to memory regions afterwards. > Would you consider adding ielftools to binutils? I would prefer to leave it as a separate project for now. I am worried about bringing in a tool that will only be of use to a very small audience (maybe just you ?) and having to maintain it. Of course if you can persuade more people to request that the sources be integrated then I can take abother look at the issue... > Note that if the linker can call an external tool to compute the CRC > based on the extracted text segment, and insert that into the resulting ELF file. > then this is superior to running a utility afterwards. Actually -- there might be a way to do this: A linker plugin. The linker already has the architecture to support plugins, and you could create a new one which would scan the text section, compute a CRC and then insert the value into a header in the linked image... Cheers Nick