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

Kai Ruottu kai.ruottu@luukku.com
Mon Jun 25 12:43:00 GMT 2001


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

 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.

 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



More information about the crossgcc mailing list