Re: [Bug ld/12565] NOLOAD sections empty

[Erik Christiansen <dvalin at internode dot on dot net>]

On 30.06.11 15:37, Nick Clifton wrote:
> Hi H.J., Hi Alan,
> 
> I have been looking at PR 12565, and I have to say that I do not
> understand the linker's behaviour for NOLOAD sections on ELF based
> targets.  What is the point of having a section that cannot be loaded
> and that does not have any contents ?

Nick, there are several practical use cases, individually described
below, mostly in embedded systems.

> Also, as far as I can see, this behaviour is not documented anywhere.

OK, a quick diversion for that: An example of perhaps the simplest case
is buried in ld.info, under the "Output Section Type" heading:

Â
   The linker normally sets the attributes of an output section based on
the input sections which map into it.  You can override this by using
the section type.  For example, in the script sample below, the `ROM'
section is addressed at memory location `0' and does not need to be
loaded when the program is run.  The contents of the `ROM' section will
appear in the linker output file as usual.
     SECTIONS {
       ROM 0 (NOLOAD) : { ... }
       ...
     }
Â

> Do you know of any applications that rely upon this feature ?

Apart from ROM, there are also sections such as ".stab", and ".debug_*".
They're definitely NOLOAD, and need to be. Mucking with them, such as by
providing an implicit NOLOAD mechanism, might only disturb hysterical
raisins, but the other cases require the explicit directive.

Some of my embedded linker scripts use NOLOAD on sections relating to
memory-mapped registers in FPGA (or other hardware) devices. The
sections conveniently pick up the addresses of the related memory
regions, for (symbolic) use in the C programs. As a result, the linker
script is the _single_document_ which defines and documents the system's
entire memory map, so there is no need to look through any code or
makefiles to search for any memory location definitions. (For me, this
is the most powerful reason for not emasculating the linker script
language, by excising a prominent and useful directive.)

Nick, I must thank you for the splendid work you've done for the V850
target (especially the "SLD and SST instructions" fix, back in 2005), as
I pause to recall that I've also used NOLOAD on the section for
"mpureg", the CPU SPR region of that target.

On the same project, I had a NOLOAD ".noinit" section, which was used to
detect a cold boot (cycled power), by reading unstructured data (no, not
nearly random, but detectably random-ish), from RAM. Gratifyingly, it
worked reliably for us in production, as well as in the lab. (The trick
was to use quite a few bytes in the sample.)

So, let's please keep NOLOAD. It's very convenient for a number of
purposes, and we'd miss it sorely if it succumbed to bitrot.

Grateful thanks, in big heaps, for the tireless efforts you guys have
put in over the years that I've delighted in using the toolchain, across
a variety of embedded targets.

Erik

-- 
Use C++ to confuse your enemies; use C to produce stable code.
                              - Wolfgang Denk, on u-boot-users.