Possible bug in m68k-rtems

Possible bug in m68k-rtems

[John Darrington]

[-- Attachment #1.1: Type: text/plain, Size: 1467 bytes --]

I have configured and built binutils with --target=m68k-rtems

Running a simple test case with the following linker script:

SECTIONS
{
  . = 0x123000;
  foo : { *(one) }
  bar : { *(two) }
}

and the following input code:

.section one
.byte 0x01, 0x02

.section two
.byte 0x03, 0x03

.end


seems to produce the wrong output, as can be seen by objdump -h:


a.out:     file format elf32-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 foo           00000002  00123000  00123000  00000034  2**0
                  CONTENTS, READONLY
  1 bar           00000002  00123000  00123000  00000036  2**0
                  CONTENTS, READONLY


As you can see, both sections have the same start address, which is incorrect.
Running the same test with a differnet configuration gives the correct results:

a.out:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 foo           00000002  00123000  00123000  00000034  2**0
                  CONTENTS, READONLY
  1 bar           00000002  00123002  00123002  00000036  2**0
                  CONTENTS, READONLY

Have I misunderstood something or is this a bug?

J'

Attached are the files I used for this test.


-- 
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 #1.2: binutils-bug.tar.gz --]
[-- Type: application/octet-stream, Size: 378 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Possible bug in m68k-rtems

[Alan Modra]

On Sun, Jul 01, 2012 at 08:01:50AM +0000, John Darrington wrote:
> a.out:     file format elf32-m68k
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 foo           00000002  00123000  00123000  00000034  2**0
>                   CONTENTS, READONLY
>   1 bar           00000002  00123000  00123000  00000036  2**0
>                   CONTENTS, READONLY
> 
> 
> As you can see, both sections have the same start address, which is incorrect.

Nope.  This is correct.  Your sections are non-alloc, so should not take
up VMA space.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Possible bug in m68k-rtems

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Sun, Jul 01, 2012 at 11:21:17PM +0930, Alan Modra wrote:
     On Sun, Jul 01, 2012 at 08:01:50AM +0000, John Darrington wrote:
     > a.out:     file format elf32-m68k
     > 
     > Sections:
     > Idx Name          Size      VMA       LMA       File off  Algn
     >   0 foo           00000002  00123000  00123000  00000034  2**0
     >                   CONTENTS, READONLY
     >   1 bar           00000002  00123000  00123000  00000036  2**0
     >                   CONTENTS, READONLY
     > 
     > 
     > As you can see, both sections have the same start address, which is incorrect.
     
     Nope.  This is correct.  Your sections are non-alloc, so should not take
     up VMA space.

In that case, the bug must be in the second example I posted, which does not show this
correct behaviour?

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Possible bug in m68k-rtems

[Alan Modra]

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.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Possible bug in m68k-rtems

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Possible bug in m68k-rtems

[Alan Modra]

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