This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug ld/12565] NOLOAD sections empty

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]