This is the mail archive of the
mailing list for the binutils project.
Re: Possible bug in m68k-rtems
On Tue, Jul 03, 2012 at 07:51:22AM +0000, John Darrington wrote:
> On Mon, Jul 02, 2012 at 11:28:49AM +0930, Alan Modra wrote:
> On Sun, Jul 01, 2012 at 02:15:47PM +0000, John Darrington wrote:
> > In that case, the bug must be in the second example I posted, which does not show this
> > correct behaviour?
> Exactly. Current ld doesn't behave as per your second example, so I
> assumed your were using some old version of ld in that case.
> You were right (of course!) I hadn't noticed that one of my builds was an older
> But I think the documentation does not explain this new behaviour. For example
> under "Output Section Type" I read "These type names ... all have the same effect:
> the section should be marked as not allocatable" It is reasonable then for the
> reader to infer, that the default is allocatable sections.
> Also, if I understand the new behaviour correctly, the example given subsection
> "Input Section Example" no longer behaves as the text says it does (unless the
> user hash explicitly marked his sections as allocatable).
In this case the linker documentation is not relevant. The sections
you used were made non-alloc by the assembler.
> In addition, it seems that only with ELF and COFF formats can the sections be
> so annotated. How does one mark a section as allocatable in the general case?
One doesn't. gas syntax varies, even amongst ELF targets.
> What was the rationale for this changed behaviour anyway? I can't think of any
> reason why a user wouldn't want memory to be allocated for a section.
Debug sections are a commonly used section that isn't allocated. I
can't remember which bug report led to this particular ld behaviour
Australia Development Lab, IBM