[ECOS] failure of "make tests" for Linux synthetic target

[ECOS] failure of "make tests" for Linux synthetic target

[Grant Edwards]

The build of the linux synthetic target for eCOS seemed to go OK, but
when I did a "make tests" it failed because of what appears to be a
linker configuration problem.  I could add bss4 and bss5 sections to
target.ld by hand, but that doesn't sound too kosher.

Anybody have any clues?

The tail end of the "make tests" output is below:

---------------------------------------------------------------------------
make[1]: Entering directory `/home/grante/ecos/ecos-1.2.1/packages/ecos-linux/hal/common/v1_2_1/tests'
i686-pc-linux-gnu-gcc  -c  -I/home/grante/ecos/ecos-1.2.1/packages/ecos-linux/install/include -I. -I/home/grante/ecos/ecos-1.2.1/packages/ecos-linux/../hal/common/v1_2_1/tests -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -ffunction-sections -fdata-sections -g -O2   -Wp,-MD,hal_intr.tmp -o hal_intr.o /home/grante/ecos/ecos-1.2.1/packages/ecos-linux/../hal/common/v1_2_1/tests/intr.c 
i686-pc-linux-gnu-gcc -o /home/grante/ecos/ecos-1.2.1/packages/ecos-linux/install/tests/hal/intr hal_intr.o  -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -ffunction-sections -fdata-sections -nostartfiles -nostdlib -Wl,--gc-sections -g -O2 -L/home/grante/ecos/ecos-1.2.1/packages/ecos-linux/install/lib -Ttarget.ld -nostdlib
/usr/local/i686-pc-linux-gnu/bin/ld: warning: no memory region specified for section `.bss4'
/usr/local/i686-pc-linux-gnu/bin/ld: warning: no memory region specified for section `.bss5'
/usr/local/i686-pc-linux-gnu/bin/ld: section .bss4 [00000000 -> 0000000b] overlaps section .text [00000000 -> 00003383]
/usr/local/i686-pc-linux-gnu/bin/ld: section .bss5 [0000000c -> 0000000f] overlaps section .text [00000000 -> 00003383]
collect2: ld returned 1 exit status
make[1]: *** [intr.stamp] Error 1
make[1]: Leaving directory `/home/grante/ecos/ecos-1.2.1/packages/ecos-linux/hal/common/v1_2_1/tests'
make: *** [tests] Error 2
---------------------------------------------------------------------------

And the contents of target.ld are:

---------------------------------------------------------------------------
STARTUP(vectors.o)
ENTRY(_start)
INPUT(extras.o)
GROUP(libtarget.a libgcc.a)
 		
MEMORY
{
    ram : ORIGIN = 0x00000000, LENGTH = 0x800000
}
SECTIONS
{
    .vectors   0x0  :      { . = . ; KEEP(*(.vectors)) } >  ram  
    .text   ALIGN (0x4)  :      { _stext = .; *(.text*) *(.gnu.warning) *(.gnu.linkonce*) *(.init) } >  ram  _etext = .;  PROVIDE (etext = .); 
    .fini   ALIGN (0x4)  :      { . = . ; *(.fini) } >  ram  
    .rodata1   ALIGN (0x8)  :      { . = . ; *(.rodata1) } >  ram  
    .rodata   ALIGN (0x8)  :      { . = . ; *(.rodata*) } >  ram  
    .fixup   ALIGN (0x4)  :      { _FIXUP_START_ = ABSOLUTE(.); *(.fixup) _FIXUP_END_ = ABSOLUTE(.);} >  ram  
    .gcc_except_table   ALIGN (0x1)  :      { _EXCEPT_START_ = ABSOLUTE(.); *(.gcc_except_table) _EXCEPT_END_ = ABSOLUTE(.);} >  ram  
    .data   ALIGN (0x8)  :      { __ram_data_start = ABSOLUTE(.); *(.data*) _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(8); __DEVTAB__ = ABSOLUTE (.); KEEP (*(SORT (.devtab*))) __DEVTAB_END__ = ABSOLUTE (.); _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) *(.eh_frame) _SDATA_START_ = ABSOLUTE(.); *(.sdata) } >  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) _SBSS_END_ = ABSOLUTE(.); *(.scommon) } >  ram  
    .bss   ALIGN (0x10)  :      { . = . ; *(.dynbss) *(.bss) *(COMMON) } >  ram  
    . = ALIGN(4); _end = .; PROVIDE (end = .); 
}
---------------------------------------------------------------------------

Re: [ECOS] failure of "make tests" for Linux synthetic target

[Jonathan Larmour]

Grant Edwards wrote:
> 
> The build of the linux synthetic target for eCOS seemed to go OK, but
> when I did a "make tests" it failed because of what appears to be a
> linker configuration problem.  I could add bss4 and bss5 sections to
> target.ld by hand, but that doesn't sound too kosher.
> 
> Anybody have any clues?
[snip]

It's certainly unclear where they're from. There's some code in the latest
gcc in cvs that produces these sections, but I thought it only did it for
arm-elf.

Try 'objdump --section-headers install/lib/libtarget.a | grep -10 bss4' to
find out what objects are giving these sections. If that doesn't find
anything, do the same for install/lib/extras.o and install/lib/vectors.o. If
that also doesn't find anything, tell me as it's probably the libgcc.a and
I'd want to know why.

What versions of the tools are you using? i.e. ' i686-pc-linux-gnu-gcc -v'.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] failure of "make tests" for Linux synthetic target

[Grant Edwards]

On Sat, Oct 23, 1999 at 03:50:06AM +0000, Jonathan Larmour wrote:
> Grant Edwards wrote:
> > 
> > The build of the linux synthetic target for eCOS seemed to go OK, but
> > when I did a "make tests" it failed because of what appears to be a
> > linker configuration problem.  I could add bss4 and bss5 sections to
> > target.ld by hand, but that doesn't sound too kosher.

[...] 

> Try 'objdump --section-headers install/lib/libtarget.a | grep -10 bss4'

No bss[45] sections ins libtarget.a or vectors.o.

However, extras.o does contain bss[45] sections:

> What versions of the tools are you using? i.e. ' i686-pc-linux-gnu-gcc -v'.

$ i686-pc-linux-gnu-gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/specs
gcc version 2.95.1 19990816 (release)

I just build the copiler last week -- I initially tried to use the
version that came with RH6.0: gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release).  But, there were some options used by the ecos
makefiles that it didn't support.

If this us just something that is due to my using a newer version of
gcc than was used when the eCOS distribution was set up, then I'll add
bss[45] sections to the .ld file and assume it's not a problem.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] failure of "make tests" for Linux synthetic target

[Jonathan Larmour]

Grant Edwards wrote:
> 
> On Sat, Oct 23, 1999 at 03:50:06AM +0000, Jonathan Larmour wrote:
> > Grant Edwards wrote:
> > >
> > > The build of the linux synthetic target for eCOS seemed to go OK, but
> > > when I did a "make tests" it failed because of what appears to be a
> > > linker configuration problem.  I could add bss4 and bss5 sections to
> > > target.ld by hand, but that doesn't sound too kosher.
> 
> > Try 'objdump --section-headers install/lib/libtarget.a | grep -10 bss4'
> 
> No bss[45] sections ins libtarget.a or vectors.o.
> 
> However, extras.o does contain bss[45] sections:
> 
> > What versions of the tools are you using? i.e. ' i686-pc-linux-gnu-gcc -v'.
> 
> $ i686-pc-linux-gnu-gcc -v
> Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/specs
> gcc version 2.95.1 19990816 (release)
> 
> I just build the copiler last week -- I initially tried to use the
> version that came with RH6.0: gcc version egcs-2.91.66 19990314/Linux
> (egcs-1.1.2 release).  But, there were some options used by the ecos
> makefiles that it didn't support.
> 
> If this us just something that is due to my using a newer version of
> gcc than was used when the eCOS distribution was set up, then I'll add
> bss[45] sections to the .ld file and assume it's not a problem.

Either that or the binutils (in particular the assembler) you are using is
quite different. I've gone through both the egcs and binutils sources and
can't find where these sections could have come from. The only potential
difference I can think of is that you'll probably be using the binutils
splinter sources from H.J. Lu and the difference is in there, but not in the
binutils mainline.

I would say just add the sections to the linker script by just changing the
*(.bss) to *(.bss*) (and I'll do it in the sources that go to anonCVS), but
it may be interesting if you could ask your question on
binutils@sourceware.cygnus.com.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] failure of "make tests" for Linux synthetic target

[Grant Edwards]

On Mon, Oct 25, 1999 at 05:15:13PM +0000, Jonathan Larmour wrote:

> > However, extras.o does contain bss[45] sections:
> > 
> > > What versions of the tools are you using? i.e. ' i686-pc-linux-gnu-gcc -v'.
> > 
> > $ i686-pc-linux-gnu-gcc -v
> > Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/specs
> > gcc version 2.95.1 19990816 (release)
> 
> Either that or the binutils (in particular the assembler) you are using is
> quite different. I've gone through both the egcs and binutils sources and
> can't find where these sections could have come from. 

I'll try to take a look at the assembly generated by gcc and see what I can see.

> The only potential difference I can think of is that you'll probably
> be using the binutils splinter sources from H.J. Lu and the
> difference is in there, but not in the binutils mainline.

I'm using binutils-991018 from the cygnus ftp site.  The standard release of
binutils supports only coff for the ARM target, and I wanted to use
elf (I don't remember why -- probably because that's what the standard ecos
setup uses).

-- 
Grant Edwards