Re: Possible bug in m68k-rtems

[John Darrington <john at darrington dot wattle dot id dot au>]

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

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.

Thanks for any enlightenment.

J'



-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature