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 8A4C83858D39 for ; Wed, 8 Feb 2023 17:36:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8A4C83858D39 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 6FF8D12020A for ; Wed, 8 Feb 2023 18:36:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com; s=default; t=1675877816; bh=/s8CC18TR14zut0CP9jZ37OzkA7+V/EhCFgozUXZEwI=; h=To:From:Subject; b=AQ5etOKexNAuh+jR8cZPN9gouY9hoys4IHf/bEETwwUsMr2ojL/nLgABBnhSWCXE8 dUYT+3amj3ySaE8UlHDItaDriCPKTGFPtLyYAKDgycWCdah/3cvZ4GpzIOsmfLb5QR 0lXkkrzfVuYSHskEV2qMUMEtZc+DlCBCr5+ylD3w= 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) Content-Type: multipart/alternative; boundary="------------9391fukvKkX3NyMZLpf5eiJW" Message-ID: Date: Wed, 8 Feb 2023 18:36:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: binutils@sourceware.org Content-Language: sv-FI From: Ulf Samuelsson Subject: RFC: generating a header using the linker (ASCII, ASCIZ commands) X-PPP-Message-ID: <167587781668.3520101.15317048604221641069@localhost.localdomain> X-PPP-Vhost: emagii.com X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_FAIL,SPF_PASS 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: This is a multi-part message in MIME format. --------------9391fukvKkX3NyMZLpf5eiJW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi guys, My very first mailing to the list. I joined due to a problem. I was involved in an embedded project using the GNU linker. 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 ============== There are a few problems involved with that. 1: You want to compute a CRC over the text area. The text area should be aligned with a flash erase sector.     We tried several approaches to align things, and gave up. We resorted to specify the size in advance.     I could not see a way to align easily to the flash boundaries and add fill- 2: How generate the CRC? It would be good to have such an application in binutils.    I ported the ielfutils from     IAR has a windows command line program which is open source (ielfutils) so     I ported that to Linux 3. You  want strings in the header. Not just BYTEs, SHORTs and LONGs etc.     It is of course possible to emulate strings using the above functions but not so nice. ============== I am thinking of adding two commands: * ASCII     , "string" * ASCIZ   "string" The ASCII command would allocate a fixed size area and would fill it from the string. If the string is shorter, then the remainder would be cleared. If the string is longer, then there would be an error message. The ASCIZ command could allocate an area large enough to store the string. =========================== I did a first prototype by patching a Yocto build. The simplest idea I could think of was to just try to create a BYTE record for each byte in the field. Obviously, creating a single field for the complete string would be better, but I have never studied the code before, so bear with me. The Yocto SDK on an U-Boot with a modified linker command file. I added.      ASCIZ "My first string" to the linker command file. The ASCIZ seems to work. checked U-Boot.bin with hexedit and my string was there. I then tried      ASCII  20, "My second string" this ASCII did not work - get a syntax error. The ASCIZ command is not flawless. Depending on the size of the string, I can get warnings: "warning: unsupported relocation type 1051152 at ffad8" =========================== A summary of the changes are: ldlex.l +"ASCII"                { RTOKEN(ASCII); } +"ASCIZ"                { RTOKEN(ASCIZ); } ldgram.y +%token ALIGN_K BLOCK BIND QUAD SQUAD LONG SHORT BYTE ASCII ASCIZ +    | ASCII INT ',' NAME +        { +          lang_add_string($2.integer, $4); +        } +    | ASCIZ NAME +        { +          lang_add_stringz($2); +        } ldlang.c +void +lang_add_string (bfd_vma size, char *s) +{ +     lang_data_statement_type *new_stmt; +     bfd_vma stringlen = strlen(s) + 1;    /* Add one for terminating '\0' */ +     bfd_vma fill_len = 0; +     if (size == 0) {  /* Zero terminated string */ +        size = stringlen; +     } else if (size > stringlen) {    /* Fix Size string */ +        fill_len = size - stringlen; +     } else if (size > stringlen) { +        /* We have an error */ +        einfo (_("%P:%pS: warning: string does not fit \"%s\"\n"), NULL, s); +     } +      /* Add byte expressions until end of string */ +     for (bfd_vma i = 0 ; i < size ; i++) { +        new_stmt = new_stat (lang_data_statement, stat_ptr); +        new_stmt->exp = exp_intop(s[i]); +        new_stmt->type = BYTE; +     } +      /* Add byte expressions for filling to the end of the string */ +     for (bfd_vma i = 0 ; i < fill_len ; i++) { +        new_stmt = new_stat (lang_data_statement, stat_ptr); +        new_stmt->exp = exp_intop(0); +        new_stmt->type = BYTE; +     } +} ... +void +lang_add_stringz (char *s) +{ +    lang_add_string (0, s); +} + On top of that, then info file is updated. *So I wonder if this type of functionality is of interest?* Also, what kind of glaring mistakes did I do for a) the ASCII statment to result in a syntax error? b) trigger the unsupported relocation. Best Regards Ulf Samuelsson --------------9391fukvKkX3NyMZLpf5eiJW--