GCC-3.0 for powerpc-eabi doesn't compile!!!
Joel Sherrill
joel.sherrill@OARcorp.com
Wed Jun 27 16:17:00 GMT 2001
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
More information about the crossgcc
mailing list