Re: [Bug ld/12565] NOLOAD sections empty

[Nick Clifton <nickc at redhat dot com>]

Hi Erik,

> > 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.

Actually the current linker documentation does not have that last sentence.

I should have been clearer in my comment however.  What I meant was the 
behaviour of the NOLOAD section type in *removing* any contents of the 
input section is not documented.  In fact that last sentence in the 
documentation ought be reinstated but it should read:

  "The contents of the 'ROM' section will be discarded and
   will not be in the output file.  If the runtime system
   chooses to create this section in the image of the application
   when it starts running then its contents will be set to zero."

Or maybe something a little bit less wordy.


> Apart from ROM, there are also sections such as ".stab", and ".debug_*".
> They're definitely NOLOAD, and need to be.

This was the starting point for this discussion.  Debugging sections 
like .stab and .debug_* must NOT be marked with NOLOAD in linker scripts 
(for ELF based targets) as otherwise their contents will be thrown away. 
 This is counter-intuitive and I was trying to find out how the 
behaviour evolved in the first place.


> 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.

OK so presumably in this scenario your loader never actually zero-fills 
these NOLOAD sections when the application starts running.  Also, 
presumably you never try to give these sections any contents, so you do 
not care that NOLOAD also means no-contents-in-the-output-file.

> 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.

I can see that changing the current behaviour of NOLOAD would be a bad 
idea, so I will not do that.  I am beginning to think that the 
documentation should be improved however, and I also think that maybe 
the linker should issue the warning if any input section assigned to an 
output section with the NOLOAD type has any non-zero contents.

Cheers
  Nick