This is the mail archive of the
mailing list for the binutils project.
Re: [Bug ld/12565] NOLOAD sections empty
- From: Nick Clifton <nickc at redhat dot com>
- To: dvalin at internode dot on dot net
- Cc: binutils at sourceware dot org
- Date: Fri, 01 Jul 2011 13:43:54 +0100
- Subject: Re: [Bug ld/12565] NOLOAD sections empty
- References: <email@example.com/bugzilla/> <bug-12565-70-H4yGNZZKA2@http.sourceware.org/bugzilla/> <4E0C8A37.firstname.lastname@example.org> <20110701081740.GA1900@ratatosk>
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.