Change in .ld syntax or a bug?

Change in .ld syntax or a bug?

[Andrew Lunn]

Hi Folks

Debian unstable is using binutils 2.16.1cvs20050902. I've found that
this causes problem with the RTOS eCos.

gcc -finline-limit=7000 -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions   -nostdlib -Wl,-r -Wl,--whole-archive -o /home/lunn/eCos/work/install/lib/extras.o /home/lunn/eCos/work/install/lib/libextras.a
gcc -L/home/lunn/eCos/work/install/lib -Ttarget.ld -o /home/lunn/eCos/work/install/tests/hal/common/current/tests/context tests/context.o -g -nostdlib -Wl,--gc-sections -Wl,-static
/usr/bin/ld: address 0x28b3 of /home/lunn/eCos/work/install/tests/hal/common/current/tests/context section .text is not within region rom
/usr/bin/ld: address 0x328b of /home/lunn/eCos/work/install/tests/hal/common/current/tests/context section .rodata is not within region rom
/usr/bin/ld: address 0x3304 of /home/lunn/eCos/work/install/tests/hal/common/current/tests/context section .eh_frame is not within region rom
/usr/bin/ld: address 0x28b3 of /home/lunn/eCos/work/install/tests/hal/common/current/tests/context section .text is not within region rom
/usr/bin/ld: address 0x328b of /home/lunn/eCos/work/install/tests/hal/common/current/tests/context section .rodata is not within region rom
/usr/bin/ld: address 0x32ec of /home/lunn/eCos/work/install/tests/hal/common/current/tests/context section .eh_frame is not within region rom
collect2: ld returned 1 exit status

If i downgrade to an older version of binutils, eg 2.16.1 it links OK.

target.ld contains:

STARTUP(vectors.o)
ENTRY(_start)
INPUT(extras.o)
GROUP(libtarget.a libgcc.a libsupc++.a libgcc_eh.a)




MEMORY
{
    rom : ORIGIN = 0x1000000, LENGTH = 0x800000
    ram : ORIGIN = 0x2000000, LENGTH = 0x800000
}

SECTIONS
{

    .vectors 0x1000000 : { . = .; KEEP(*(.vectors)) } > rom
    .text ALIGN (0x4) : { _stext = .; *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init) } > rom _etext = .; PROVIDE (etext = .);
    .fini ALIGN (0x4) : { . = .; *(.fini) } > rom
    .rodata1 ALIGN (0x8) : { . = .; *(.rodata1) } > rom
    .rodata ALIGN (0x8) : { . = .; *(.rodata*) *(.gnu.linkonce.r.*) } > rom
    .fixup ALIGN (0x4) : { _FIXUP_START_ = ABSOLUTE(.); *(.fixup) _FIXUP_END_ =
ABSOLUTE(.);} > rom
    .rel.text : { *(.rel.text) *(.rel.text.*) *(.rel.gnu.linkonce.t*) } > rom .rela.text : { *(.rela.text) *(.rela.text.*) *(.rela.gnu.linkonce.t*) } > rom .rel.data : { *(.rel.data) *(.rel.data.*) *(.rel.gnu.linkonce.d*) } > rom .rela.data : { *(.rela.data) *(.rela.data.*) *(.rela.gnu.linkonce.d*) } > rom .rel.rodata
: { *(.rel.rodata) *(.rel.rodata.*) *(.rel.gnu.linkonce.r*) } > rom .rela.rodata : { *(.rela.rodata) *(.rela.rodata.*) *(.rela.gnu.linkonce.r*) } > rom .rel.got : { *(.rel.got) } > rom .rela.got : { *(.rela.got) } > rom .rel.ctors : { *(.rel.ctors) } > rom .rela.ctors : { *(.rela.ctors) } > rom .rel.dtors : { *(.rel.dtors) } > rom .rela.dtors : { *(.rela.dtors) } > rom .rel.init : { *(.rel.init) } > rom .rela.init : { *(.rela.init) } > rom .rel.fini : { *(.rel.fini) } > rom .rela.fini : { *(.rela.fini) } > rom .rel.bss : { *(.rel.bss) } > rom .rela.bss : { *(.rela.bss) } > rom .rel.plt : { *(.rel.plt) } > rom .rela.plt : { *(.rela.plt) } > rom .rel.dyn : { *(.rel.dyn) } > rom
    .eh_frame ALIGN (0x4) : { . = .; __EH_FRAME_BEGIN__ = .; KEEP(*(.eh_frame))
__FRAME_END__ = .; . = . + 8; } > rom = 0
    .rel.got ALIGN (0x1) : { *(.rel.got) } > rom
    .gcc_except_table ALIGN (0x1) : { _EXCEPT_START_ = ABSOLUTE(.); *(.gcc_except_table) _EXCEPT_END_ = ABSOLUTE(.);} > rom
    .data 0x2000000 : { __ram_data_start = ABSOLUTE(.); *(.data*) *(.gnu.linkonce.d.*) _GOT1_START_ = ABSOLUTE(.); *(.got1) _GOT1_END_ = ABSOLUTE(.); . = ALIGN(8); __CTOR_LIST__ = ABSOLUTE(.); KEEP(*(SORT(.ctors*))) __CTOR_END__ = ABSOLUTE(.); __DTOR_LIST__ = ABSOLUTE(.); KEEP(*(SORT(.dtors*))) __DTOR_END__ = ABSOLUTE(.); . = ALIGN(32); KEEP(*( SORT (.ecos.table.*))); _GOT2_START_ = ABSOLUTE(.); *(.got2) _GOT2_END_ = ABSOLUTE(.); _GOT_START_ = ABSOLUTE(.); _GLOBAL_OFFSET_TABLE_ = ABSOLUTE(. + 32768); _SDA_BASE_ = ABSOLUTE(.); *(.got.plt) *(.got) _GOT_END_ = ABSOLUTE(.); *(.dynamic) _SDATA_START_ = ABSOLUTE(.); *(.sdata*) *(.gnu.linkonce.s.*) } > ram __rom_data_start = LOADADDR(.data); __ram_data_end = .; PROVIDE(__ram_data_end = .); _edata = .; PROVIDE (edata = .);
    .sbss ALIGN (0x4) : { __bss_start = ABSOLUTE (.); _SBSS_START_ = ABSOLUTE(.); *(.sbss*) *(.gnu.linkonce.sb.*) _SBSS_END_ = ABSOLUTE(.); *(.scommon*) } > ram    .bss ALIGN (0x10) : { . = .; *(.dynbss*) *(.bss*) *(COMMON) *(.gnu.linkonce.b.*) } > ram __bss_end = .;
    __heap1 = ALIGN (0x10);
    . = ALIGN(4); _end = .; PROVIDE (end = .);
}

It looks like ld is happy with sections which explicit set there
address, eg .vectors and .data, but sections which just follow on from
the previous section it is not happy with and seems to put them
outside of memory.

Has there recently been a change in syntax? Or is this a bug?

    Thanks
        Andrew

Re: Change in .ld syntax or a bug?

[Alan Modra]

On Thu, Sep 15, 2005 at 02:17:08PM +0200, Andrew Lunn wrote:
> It looks like ld is happy with sections which explicit set there
> address, eg .vectors and .data, but sections which just follow on from
> the previous section it is not happy with and seems to put them
> outside of memory.
> 
> Has there recently been a change in syntax? Or is this a bug?

A bug, I suspect.  Do you have anything in .vectors?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Change in .ld syntax or a bug?

[Andrew Lunn]

On Thu, Sep 15, 2005 at 10:50:26PM +0930, Alan Modra wrote:
> On Thu, Sep 15, 2005 at 02:17:08PM +0200, Andrew Lunn wrote:
> > It looks like ld is happy with sections which explicit set there
> > address, eg .vectors and .data, but sections which just follow on from
> > the previous section it is not happy with and seems to put them
> > outside of memory.
> > 
> > Has there recently been a change in syntax? Or is this a bug?
> 
> A bug, I suspect.  Do you have anything in .vectors?

Humm, interesting. No, its empty according to --print-map.

I edited target.ld and removed the .vectors section and gave .text a
fixed start address. It then linked happily. 

So it looks like ld cannot correctly follow on from an empty section.

   Andrew

Re: Change in .ld syntax or a bug?

[Alan Modra]

On Thu, Sep 15, 2005 at 03:33:22PM +0200, Andrew Lunn wrote:
> On Thu, Sep 15, 2005 at 10:50:26PM +0930, Alan Modra wrote:
> > On Thu, Sep 15, 2005 at 02:17:08PM +0200, Andrew Lunn wrote:
> > > It looks like ld is happy with sections which explicit set there
> > > address, eg .vectors and .data, but sections which just follow on from
> > > the previous section it is not happy with and seems to put them
> > > outside of memory.
> > > 
> > > Has there recently been a change in syntax? Or is this a bug?
> > 
> > A bug, I suspect.  Do you have anything in .vectors?
> 
> Humm, interesting. No, its empty according to --print-map.
> 
> I edited target.ld and removed the .vectors section and gave .text a
> fixed start address. It then linked happily. 
> 
> So it looks like ld cannot correctly follow on from an empty section.

Would you mind checking whether mainline CVS has this bug?  If you find
it does, I'll see about fixing the problem.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Change in .ld syntax or a bug?

[Andrew Lunn]

On Fri, Sep 16, 2005 at 11:56:47AM +0930, Alan Modra wrote:
> On Thu, Sep 15, 2005 at 03:33:22PM +0200, Andrew Lunn wrote:
> > On Thu, Sep 15, 2005 at 10:50:26PM +0930, Alan Modra wrote:
> > > On Thu, Sep 15, 2005 at 02:17:08PM +0200, Andrew Lunn wrote:
> > > > It looks like ld is happy with sections which explicit set there
> > > > address, eg .vectors and .data, but sections which just follow on from
> > > > the previous section it is not happy with and seems to put them
> > > > outside of memory.
> > > > 
> > > > Has there recently been a change in syntax? Or is this a bug?
> > > 
> > > A bug, I suspect.  Do you have anything in .vectors?
> > 
> > Humm, interesting. No, its empty according to --print-map.
> > 
> > I edited target.ld and removed the .vectors section and gave .text a
> > fixed start address. It then linked happily. 
> > 
> > So it looks like ld cannot correctly follow on from an empty section.
> 
> Would you mind checking whether mainline CVS has this bug?  If you find
> it does, I'll see about fixing the problem.

I just tried anoncvs trunk and it has the same problem.

  Thanks
    Andrew

Re: Change in .ld syntax or a bug?

[Alan Modra]

On Fri, Sep 16, 2005 at 09:32:39AM +0200, Andrew Lunn wrote:
> On Fri, Sep 16, 2005 at 11:56:47AM +0930, Alan Modra wrote:
> > On Thu, Sep 15, 2005 at 03:33:22PM +0200, Andrew Lunn wrote:
> > > So it looks like ld cannot correctly follow on from an empty section.
> > 
> > Would you mind checking whether mainline CVS has this bug?  If you find
> > it does, I'll see about fixing the problem.
> 
> I just tried anoncvs trunk and it has the same problem.

Please let me know whether this cures the problem.

	* ldlang.c (lang_size_sections_1): Process addr_tree earlier,
	so that unused output section statements affect dot.

Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.195
diff -u -p -r1.195 ldlang.c
--- ld/ldlang.c	4 Aug 2005 06:22:12 -0000	1.195
+++ ld/ldlang.c	19 Sep 2005 02:36:44 -0000
@@ -3973,10 +3973,30 @@ lang_size_sections_1
 	    bfd_vma newdot, after;
 	    lang_output_section_statement_type *os;
 
+	    newdot = dot;
 	    os = &s->output_section_statement;
+	    if (os->addr_tree != NULL)
+	      {
+		os->processed = -1;
+		exp_fold_tree (os->addr_tree, bfd_abs_section_ptr,
+			       &newdot);
+		os->processed = 0;
+
+		if (!expld.result.valid_p
+		    && expld.phase != lang_mark_phase_enum)
+		  einfo (_("%F%S: non constant or forward reference"
+			   " address expression for section %s\n"),
+			 os->name);
+
+		newdot = expld.result.value + expld.result.section->vma;
+	      }
+
 	    if (os->bfd_section == NULL)
-	      /* This section was removed or never actually created.  */
-	      break;
+	      {
+		/* This section was removed or never actually created.  */
+		dot = newdot;
+		break;
+	      }
 
 	    /* If this is a COFF shared library section, use the size and
 	       address from the input section.  FIXME: This is COFF
@@ -4074,22 +4094,6 @@ lang_size_sections_1
 				 os->name, (unsigned long) (newdot - savedot));
 		      }
 		  }
-		else
-		  {
-		    newdot = dot;
-		    os->processed = -1;
-		    exp_fold_tree (os->addr_tree, bfd_abs_section_ptr,
-				   &newdot);
-		    os->processed = 0;
-
-		    if (!expld.result.valid_p
-			&& expld.phase != lang_mark_phase_enum)
-		      einfo (_("%F%S: non constant or forward reference"
-			       " address expression for section %s\n"),
-			     os->name);
-
-		    newdot = expld.result.value + expld.result.section->vma;
-		  }
 
 		/* The section starts here.
 		   First, align to what the section needs.  */

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Change in .ld syntax or a bug?

[Andrew Lunn]

On Mon, Sep 19, 2005 at 12:25:03PM +0930, Alan Modra wrote:
> On Fri, Sep 16, 2005 at 09:32:39AM +0200, Andrew Lunn wrote:
> > On Fri, Sep 16, 2005 at 11:56:47AM +0930, Alan Modra wrote:
> > > On Thu, Sep 15, 2005 at 03:33:22PM +0200, Andrew Lunn wrote:
> > > > So it looks like ld cannot correctly follow on from an empty section.
> > > 
> > > Would you mind checking whether mainline CVS has this bug?  If you find
> > > it does, I'll see about fixing the problem.
> > 
> > I just tried anoncvs trunk and it has the same problem.
> 
> Please let me know whether this cures the problem.

Nope.

I've created a bugzilla bug, #1353. I've also created a testcase which
demonstrates the bug. Detains are in bugzilla.

     Thanks
        Andrew        

Re: Change in .ld syntax or a bug?

[Alan Modra]

On Mon, Sep 19, 2005 at 09:42:46AM +0200, Andrew Lunn wrote:
> On Mon, Sep 19, 2005 at 12:25:03PM +0930, Alan Modra wrote:
> > Please let me know whether this cures the problem.
> 
> Nope.
> 
> I've created a bugzilla bug, #1353. I've also created a testcase which
> demonstrates the bug. Detains are in bugzilla.

Thanks.  So it's not that .vectors has no bfd_section created, but that
the section is zero sized.  The change to ignore alignment in zero size
sections also affects sections with an explicit address.

I've committed this patch to mainline.

	* ldlang.c (lang_size_sections_1): Process addr_tree earlier,
	so that unused output section statements affect dot.

Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.195
diff -u -p -r1.195 ldlang.c
--- ld/ldlang.c	4 Aug 2005 06:22:12 -0000	1.195
+++ ld/ldlang.c	19 Sep 2005 23:10:46 -0000
@@ -3974,6 +3974,21 @@ lang_size_sections_1
 	    lang_output_section_statement_type *os;
 
 	    os = &s->output_section_statement;
+	    if (os->addr_tree != NULL)
+	      {
+		os->processed = -1;
+		exp_fold_tree (os->addr_tree, bfd_abs_section_ptr, &dot);
+		os->processed = 0;
+
+		if (!expld.result.valid_p
+		    && expld.phase != lang_mark_phase_enum)
+		  einfo (_("%F%S: non constant or forward reference"
+			   " address expression for section %s\n"),
+			 os->name);
+
+		dot = expld.result.value + expld.result.section->vma;
+	      }
+
 	    if (os->bfd_section == NULL)
 	      /* This section was removed or never actually created.  */
 	      break;
@@ -4003,6 +4018,7 @@ lang_size_sections_1
 		break;
 	      }
 
+	    newdot = dot;
 	    if (bfd_is_abs_section (os->bfd_section))
 	      {
 		/* No matter what happens, an abs section starts at zero.  */
@@ -4074,22 +4090,6 @@ lang_size_sections_1
 				 os->name, (unsigned long) (newdot - savedot));
 		      }
 		  }
-		else
-		  {
-		    newdot = dot;
-		    os->processed = -1;
-		    exp_fold_tree (os->addr_tree, bfd_abs_section_ptr,
-				   &newdot);
-		    os->processed = 0;
-
-		    if (!expld.result.valid_p
-			&& expld.phase != lang_mark_phase_enum)
-		      einfo (_("%F%S: non constant or forward reference"
-			       " address expression for section %s\n"),
-			     os->name);
-
-		    newdot = expld.result.value + expld.result.section->vma;
-		  }
 
 		/* The section starts here.
 		   First, align to what the section needs.  */

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre