* Change in .ld syntax or a bug? @ 2005-09-15 13:01 Andrew Lunn 2005-09-15 13:39 ` Alan Modra 0 siblings, 1 reply; 8+ messages in thread From: Andrew Lunn @ 2005-09-15 13:01 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Change in .ld syntax or a bug? 2005-09-15 13:01 Change in .ld syntax or a bug? Andrew Lunn @ 2005-09-15 13:39 ` Alan Modra 2005-09-15 13:43 ` Andrew Lunn 0 siblings, 1 reply; 8+ messages in thread From: Alan Modra @ 2005-09-15 13:39 UTC (permalink / raw) To: Andrew Lunn; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Change in .ld syntax or a bug? 2005-09-15 13:39 ` Alan Modra @ 2005-09-15 13:43 ` Andrew Lunn 2005-09-16 5:36 ` Alan Modra 0 siblings, 1 reply; 8+ messages in thread From: Andrew Lunn @ 2005-09-15 13:43 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Change in .ld syntax or a bug? 2005-09-15 13:43 ` Andrew Lunn @ 2005-09-16 5:36 ` Alan Modra 2005-09-16 8:25 ` Andrew Lunn 0 siblings, 1 reply; 8+ messages in thread From: Alan Modra @ 2005-09-16 5:36 UTC (permalink / raw) To: Andrew Lunn; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Change in .ld syntax or a bug? 2005-09-16 5:36 ` Alan Modra @ 2005-09-16 8:25 ` Andrew Lunn 2005-09-19 7:44 ` Alan Modra 0 siblings, 1 reply; 8+ messages in thread From: Andrew Lunn @ 2005-09-16 8:25 UTC (permalink / raw) To: amodra; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Change in .ld syntax or a bug? 2005-09-16 8:25 ` Andrew Lunn @ 2005-09-19 7:44 ` Alan Modra 2005-09-19 14:23 ` Andrew Lunn 0 siblings, 1 reply; 8+ messages in thread From: Alan Modra @ 2005-09-19 7:44 UTC (permalink / raw) To: Andrew Lunn; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Change in .ld syntax or a bug? 2005-09-19 7:44 ` Alan Modra @ 2005-09-19 14:23 ` Andrew Lunn 2005-09-20 2:59 ` Alan Modra 0 siblings, 1 reply; 8+ messages in thread From: Andrew Lunn @ 2005-09-19 14:23 UTC (permalink / raw) To: amodra; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Change in .ld syntax or a bug? 2005-09-19 14:23 ` Andrew Lunn @ 2005-09-20 2:59 ` Alan Modra 0 siblings, 0 replies; 8+ messages in thread From: Alan Modra @ 2005-09-20 2:59 UTC (permalink / raw) To: Andrew Lunn; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-09-19 23:18 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-09-15 13:01 Change in .ld syntax or a bug? Andrew Lunn 2005-09-15 13:39 ` Alan Modra 2005-09-15 13:43 ` Andrew Lunn 2005-09-16 5:36 ` Alan Modra 2005-09-16 8:25 ` Andrew Lunn 2005-09-19 7:44 ` Alan Modra 2005-09-19 14:23 ` Andrew Lunn 2005-09-20 2:59 ` Alan Modra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).