This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |