Re: [Bug ld/12565] NOLOAD sections empty

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

On 01.07.11 13:43, Nick Clifton wrote:
> Erik wrote:
> > 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.

OK, then it looks a lot like the behaviour has changed over time, but
without anyone being inconvenienced.

Was it overlays which most needed content retention for multiple output
sections, but allocation for only one of them? That would perhaps
explain why the changed behaviour has not been noticed.

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

That reads suitably explicit. However, because the original being
modified there is somewhat buried, the primary description of NOLOAD
behaviour needs part of the explanation, to give users a fair chance, I
think. Minimally something along the lines of:

`NOLOAD'
     The section should be marked as not loadable, so that it will not
     be loaded into memory when the program is run. The CONTENTS will be
     discarded, and will not be present in the output file either.

That does reveal that the behaviour has changed. A more concise form
might be:

`NOLOAD'
     The CONTENTS of the section will be discarded. Its absence from the
     output file leaves nothing of this section to load into memory when
     the program is run.

Making CONTENTS uppercase favours grepping of what we see in the output
of objdump, etc.

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

Agreed, if ld is no longer retaining content in the output file.

Admittedly, the fact that the previously mentioned embedded projects
hadn't made me aware of loss of content in the output file confirms that
content wasn't needed in those use cases. 

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

True.

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

That sounds like it could be a step forward from the status quo.

If there's ever need to replicate the old NOLOAD behaviour, we can still
(at least for an ELF output file) just leave off the "a" section flag
on an unrecognised section name. That results in content retention, but
no LOAD or ALLOC flags:

   .section .fred
   .ascii "wefwpoergfbodfkobpsbflpkmscg"

$ avr-objdump -h section_flags.o
   ...
   0 .text         00000018  00000000  00000000  00000034  2**0
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   ...
   3 .fred         0000001c  00000000  00000000  0000004c  2**0
                   CONTENTS, READONLY 

And the content is really there, not just a size:

$ avr-objdump -D section_flags.o
   ...
00000000 <.fred>:
   0:   77 65           ori     r23, 0x57       ; 87
   2:   66 77           andi    r22, 0x76       ; 118
   4:   70 6f           ori     r23, 0xF0       ; 240
   6:   65 72           andi    r22, 0x25       ; 37
   ...

So no capability has been irretrievably lost from the toolchain. 

Erik

-- 
The tools we use have a profound and devious influence on our thinking
habits, and therefore on our thinking abilities.
                                                     -Edsgar W. Dijkstra