Re: GCC-3.0 for powerpc-eabi doesn't compile!!!

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Kai Ruottu wrote:
> 
> Joćo Cadamuro Junior wrote:
> >
> > Kai Ruottu wrote:
> >
> > >  If browsing this list some weeks back, the binutils-2.11 and ppc-eabi
> > > issue should be seen... Using binutils-2.10.1 or newer snapshots should
> > > work with powerpc-eabi, but please check the messages first...
> >
> > I remember something some days ago... In my mind you are talking about:
> >
> > http://sources.redhat.com/ml/crossgcc/2001-q2/msg00401.html
> 
>  The earlier troubles seemed to be related to linking, so my memories about
> the binutils-2.11/ppc-eabi issue didn't suit to this case...
> 
>  You did find a bug and a unworking target more in gcc-3.0 ...
> 
> > Anyway, I tryied to build gcc-3.0 again using binutils-2.10.1, and I get
> > exactly the same result!!!
> 
>   I have only the gcc-3.0 and 3.0.1 prereleases (the snapshots), but the
> gcc-20010618 snapshots gave just the same result. The error and the resulted
> assembly I got was:
> 
> -------- the error got from build -----------
> 
> /tmp/ccmNhRjd.s: Assembler messages:
> /tmp/ccmNhRjd.s:126: Error: Relocation cannot
> be done when using -mrelocatable
> 
> -------- the generated asm code -------------
> 
>         .section        ".data"
>         .align 2
> .LLSDA1:
>         .byte   0xff
>         .byte   0x0
>  <snip>
>         .byte   0x0
>         .byte   0x7d
>         .align 2
>         .4byte  _ZTISt9bad_alloc     <--- the line 126 !!!!!!!
>         .byte   0x1
>         .byte   0x0
>         .section        ".text"
>         .weak   _ZTSSt9bad_alloc
>         .section        ".gnu.linkonce.s._ZTSSt9bad_alloc","aw"
>         .align 2
>         .type   _ZTSSt9bad_alloc,@object
>         .size   _ZTSSt9bad_alloc,13
> _ZTSSt9bad_alloc:
>         .string "St9bad_alloc"
>         .weak   _ZTISt9bad_alloc
>         .section        ".gnu.linkonce.s._ZTISt9bad_alloc","aw"
>         .align 2
>         .type   _ZTISt9bad_alloc,@object
>         .size   _ZTISt9bad_alloc,12
> _ZTISt9bad_alloc:
> .LCP0:
>         .long (_ZTVN10__cxxabiv120__si_class_type_infoE+8)@fixup
>         .section        ".fixup","aw"
>         .align 2
>         .long   .LCP0
>         .previous
> .LCP1:
>         .long (_ZTSSt9bad_alloc)@fixup
>         .section        ".fixup","aw"
> ----------------- clip -----------------------------
> 
>  So the '_ZTISt9bad_alloc' is an address in another section. An earlier
> 
>         .long  _ZTISt9bad_alloc
> 
> was approved, but what is wrong in the '.4byte' and why the address given
> with it cannot be relocated goes beyond my knowledge...
> 
> > Someone desires to give another suggestion???
> >
> > I'm thinking in post the original message into gcc-help list...
> 
>  Lets hope the previous code sample lets some PPC-guru to get a clue...
> 
>  BTW, I did a check with the gcc-3.0 prerelease perhaps two weeks ago
> and got the following results with six quite random embedded targets:
> 
>  Target            Does it work in gcc-3.0
> ----------------------------------------------
>  fr30-elf          No, the build crashes
>  m32r-elf          No, the build crashes
>  mn10200-elf       No, the build crashes
>  mn10300-elf       Yes, the build succeeds
>  i386-elf          Yes, the build succeeds
>  v850-elf          No, the build crashes

v850-elf is working now on 3.0-CVS

>  Only 2 from the 6 already working (2 from 7 now) didn't hint the gcc-3.0
> to appear 'Really soon now', but it appeared anyhow... All the crashes
> were because of internal errors. I will probably try these again and
> will also try some other targets too, but with the gcc-3.0.1 snapshots.

This corresponds to my experiences.  I have tried to build about 18 non-RTEMS
targets and about 10 RTEMS ones.  I have filed bug reports on the 
20010527, 20010611, and 3.0 CVS tree.  Some of these have been fixed.  Others
have not.

My similar summary using binutils 2.11.2, nelwib 1.9.0,
and gcc 3.0-cvs for C/C++ only is:

 Target            Does it work in gcc-3.0
----------------------------------------------
a29k-coff       fails, possible patch applied to mainline
arc-elf         fails, some multilib/crtinit configure problem
arm-elf         builds
h8300-coff      builds (requires patch)
hppa1.1-proelf  fails
i386-elf        builds
i960-coff       fails, internal compiler error
i960-elf        fails, libgcc1 test
m68k-coff       fails, internal compiler error
m68k-elf        fails, same internal compiler error
mips-elf        builds
mips64orion-elf fails (might be local though)
powerpc-elf     fails (might be local though, I used to
                       get the same -mrelocatble problem)
sh-coff         fails (binutils assert)
sh-elf          builds
sparc-elf       builds
v850-elf        fails, "undefined symbol _ in operation"

I am getting similar results for the comparable *-rtems targets
When you enable other languages the failures get worse.

>  Getting the gcc-3.0 release from the gcc-3.0 prereleases or from the odd
> 'gcc-3.0-20010527' release isn't supported via diffs at all and so keeps
> the snapshots-builders and the release-builders as separate groups... Why
> the possibility to get the 3.0 release from the gcc-20010611-snapshots is
> not offered is one of those things I don't understand.


 
> Cheers, Kai
> 
> PS. I got the m32r-elf result already, the build crashed with the following
> error in libstdc++-v3 :
> 
> ------------------------- clip ------------------------------------
>  -c ../../../../../libstdc++-v3/src/functexcept.cc -o functexcept.o
> /tmp/ccErEvcj.s: Assembler messages:
> /tmp/ccErEvcj.s:812: Error: Bad expression
> /tmp/ccErEvcj.s:827: Error: bad instruction `bl '
> /tmp/ccErEvcj.s:830: Error: Bad expression
> /tmp/ccErEvcj.s:831: Error: Bad expression
> /tmp/ccErEvcj.s:852: Error: Bad expression
> /tmp/ccErEvcj.s:862: Error: Bad expression
> /tmp/ccErEvcj.s:880: Error: bad instruction `bl @^D^C#@'
> /tmp/ccErEvcj.s:943: Error: Bad expression
> /tmp/ccErEvcj.s:958: Error: bad instruction `bl '
> /tmp/ccErEvcj.s:979: Error: Bad expression
> /tmp/ccErEvcj.s:989: Error: Bad expression
> /tmp/ccErEvcj.s:1007: Error: bad instruction `bl @^D^C#@'
> ------------------------- clip ------------------------------------
> 
>  Not so good code generation for Mitsubishis either...
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com