Re: RFC: generating a header using the linker (ASCII, ASCIZ commands)

[Ulf Samuelsson <binutils@emagii.com>]

Den 2023-02-13 kl. 11:09, skrev Nick Clifton:
> Hi Ulf,
>
>> My very first mailing to the list. 
>
> Well then welcome to the binutils community.
>
>
>> 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.


>> The text area should be aligned with a flash erase sector.
>
> This should be possible using a linker script.  You can use the MEMORY
> directive to specify the flash memory region(s) and the various section
> alignment and assignment directives to put the text section where you
> want.

I have not found a way.

I can put the text where I want it, but I do not not know the size of 
the application until link time.

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

I have not found a way to do this, so my workaround is to specify the 
size to be 192kB.
This sort of works, until it doesn't, and I have to change the setup.

>
>
>>      I could not see a way to align easily to the flash boundaries 
>> and add fill-
>
> Perhaps you could provide an example of what you want to achieve ?
> I am pretty sure that it can be done using linker script directives.
>
>
>> 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
>
> Well if you already have a tool, then that is fine.
>
> It is true that the binutils does not have a tool specifically for the 
> creation
> of CRCs, but then that does seem to be a bit of a niche application.

In the linux world, it is certainly a niche thing.

In embedded control, this is considered good practice.
In safety applications, CRC checks are mandatory.

The way I would support CRC is to generate a command file in the linker 
for a tool which inserts the CRC.

Having the CRC generation utility inside binutils simplifies things.

> In theory you might be able to use the objcopy command to extract the 
> text section
> which you could then pass to a tool to generate the CRC.

There are two alternatives.

1. Generate the CRC on the binary (your suggestion).

2. Generate the CRC in the ELF file (implemented in ielfutils).

The latter is neccessary if you want to be able to
debug the application. The debugger downloads from the ELF file, and not 
the binary.

Would you consider adding ielftools to binutils?

This is the IAR license which looks OK to me.

///////////////////////////////// -*- C++ -*- 
/////////////////////////////////
/*
  * Copyright 2007-2017 IAR Systems AB.
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */

I have ported it to linux here

https://github.com/emagii/ielftool.git

Since ielftool was created for the IAR Embedded Workbench, there are some
small things that needs handholding. I had to add fill value == 0x00
to get it to work properly, but after that I managed to use it successfully
on something linked with the binutils linker.

With more exposure, things like that are probably going to get fixed 
quicker.

====

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.

Working on a an extracted text segment is of course much easier
than working on an ELF file.

> Also - could you use the build-id mechanism instead ?  That would 
> create a
> special section containing a CRC-like value which your run-time system 
> could
> access.

Had a quick look at this and this is how I understand it.

"The build-id is computed over the ELF header"

We need to compute it over the valid flash sections.

We also need to be able to select the SYNDROME and not SHA1.

Some chips (I.E: TMS570xxx) have CRC checking hardware, and using them 
is much faster than
computing the CRC in software. In many systems, you compute CRC before 
you start the application
but in safety critical systems, you need to recompute CRC continuously. 
Then performance is an issue.

>> 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.
>
> Agreed.  Having a couple of string directives supported in the linker
> syntax would be nice.

I tried to implement

     ASCIZ "string"

     ASCII  size, "string"

Only got the ASCIZ to work.

I tried the ASCII and got a syntax error whenever I tested.

I therefore sent a patchset with only the ASCIZ string command

I am a newbie on the code, so if I can get someone to review the 
non-working code
I can perhaps get the ASCII command right.
I think that should be a second step.

>> Depending on the size of the string, I can get warnings: "warning: 
>> unsupported relocation type 1051152 at ffad8"
>
> Hmmm, this looks like memory corruption of some kind.

I tested this while linking U-Boot.
After testing a few things, I think that this is specfic to U-Boot and 
actually not a real problem.

SECTIONS
{
  . = 0x00000000;
  . = ALIGN(4);
  .text :
  {

   /* ASCIZ statement here generates a problem */

   *(.__image_copy_start)

   /* ASCIZ statement here does not generates a problem */

   *(.vectors)
   arch/arm/cpu/armv7/start.o (.text*)
  }

I suspect that there are a lot of object files accessing something in 
the ".__image_copy_start" section
using short relative addressing, and if something is added before the 
section, it breaks.

The same problem occurs when I add BYTE statements at the wrong location.
> I looked over the code you provided and it looks good, but that
> was just a visual check.  I would have to have an actual reproducer
> in order to investigate further.

Does that mean that you will try to build with the patches?

If not, what does it mean?

I provided a patchset for the ASCIZ command to the mailing list on 
2023-02-10 18:44

Unfortunately with  an empty header.

I build using Yocto, and can provide the bbappend with the patches, if 
it is of any help.
>> +     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;
>> +     }
>
> FYI - this loop (and the one below) could be simplified to:
>
>   for (bfd_vma i = 0; i < size; i++)
>     lang_add_data (BYTYE, exp_intop(s[i]);
>
I can update the patch, but perhaps we should wait until you tested the 
first patch.

Best Regards
Ulf Samuelsson