[PATCH] D43228: [ELF] Allow redefining LMA for a section inside a segment.

[Igor Kudrin via llvm-commits]

> Another way of saying that is that the image is its own loader. That is
> also true for ld.so too for example.

With ld.so you, at least, have an ELF file with the headers. With ROM you don't have ELF at all.

> Is there any reason why the linker script cannot be changed to have
> multiple PT_LOADs?

It is mainly a convenience for the next step tools. You don't need to reconstruct the continuous image from multiple blocks. You just need to extract one prepared segment. And the approach works as expected with GNU ld.

Another reason is what lld right now does not process linker scripts like that accurately enough. In fact, it ignores LMA settings for the second and following sections in the segment. It would be more coherent if it issued an error in that case, for example. But why don't just allow a user to get what they want?

Best Regards,
Igor Kudrin
C++ Developer, Access Softek, Inc.

________________________________________
From: Rafael Avila de Espindola <rafael.espindola at gmail.com>
Sent: Friday, February 23, 2018 8:48 AM
To: Igor Kudrin; reviews+D43228+public+3f65b968bcd3310a at reviews.llvm.org; ruiu at google.com
Cc: Evgeny Leviant; George Rimar; emaste at freebsd.org; llvm-commits at lists.llvm.org; arichardson.kde at gmail.com; pshung807 at gmail.com; adhemerval.zanella at linaro.org
Subject: Re: [PATCH] D43228: [ELF] Allow redefining LMA for a section inside a segment.

Igor Kudrin <ikudrin at accesssoftek.com> writes:

> The use case of a ROM image is a bit different. You don't have an OS, you don't have a loader, you even don't have an ELF file with ELF headers. All you have is an image, and a computer just starts execution from a predefined address. Everything else has to be done by the code in that image itself, including, in particular, initialization of R/W data by copying the corresponding block from ROM to RAM.

Another way of saying that is that the image is its own loader. That is
also true for ld.so too for example.

> When you prepare a ROM image, an ELF file is only an intermediate step. Other tools extract the final image, and it is much more convenient for them if there is only one PT_LOAD segment in the ELF file, because it is closer to the final layout.
>
> Please note, that if a linker script does not explicitly define desired segments for output sections, the generated output will still have separate PT_LOADs for each customized LMA. Nothing is changed here. The patch just allows a user to accurately specify their needs. As you may see, all the existing tests stay intact, and I merely add a new use case, which was not covered.

So what are the needs? If there are two areas in the file that the image
will process differently (like the example in the binutils manual), then
it is very reasonable to have them in different PT_LOADs.

Is there any reason why the linker script cannot be changed to have
multiple PT_LOADs?

>
> By the way, where does the idea of the uniform difference between
> VMAs, LMAs, and offsets within one segment come from? It might seem
> logical and natural, but I cannot find it as a requirement in the ELF
> specs.

>From the very idea of what a PT_LOAD is.

Cheers,
Rafael