Re: Possible bug in m68k-rtems

[Alan Modra <amodra at gmail dot com>]

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

-- 
Alan Modra
Australia Development Lab, IBM