HI, openbios guys,
Today i compiled openbios on my ppc64 box, encoutered some questions:
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc64 ppc64 ppc64 GNU/Linux
[root@945n03 openbios]# rpm -qa | grep glibc glibc-2.11-2.ppc glibc-2.11-2.ppc64 glibc-devel-2.11-2.ppc glibc-common-2.11-2.ppc glibc-headers-2.11-2.ppc
[root@945n03 openbios]# rpm -qa | grep gcc libgcc-4.4.2-7.fc12.ppc64 gcc-4.4.2-7.fc12.ppc libgcc-4.4.2-7.fc12.ppc gcc-c++-4.4.2-7.fc12.ppc gcc-gfortran-4.4.2-7.fc12.ppc
[root@945n03 openbios]# gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC)
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc64 for ppc ERROR: no powerpc cross-compiler found !
When i run "setarch 32 bash", "switch-arch" can work well, but it fails to run "make"
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc ppc ppc GNU/Linux
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc for ppc Initializing build tree obj-ppc...ok. Creating target Makefile...ok. Creating config files...ok.
Building OpenBIOS for ppc Building...error: /kvm/openbios/obj-ppc/../libc/string.c:499: undefined reference to `_restgpr_31_x' liblibc.a(vsprintf.o): In function `number': /kvm/openbios/obj-ppc/../libc/vsprintf.c:55: undefined reference to `_savegpr_19' /kvm/openbios/obj-ppc/../libc/vsprintf.c:145: undefined reference to `_restgpr_19_x' liblibc.a(vsprintf.o): In function `vsnprintf': /kvm/openbios/obj-ppc/../libc/vsprintf.c:158: undefined reference to `_savegpr_22' /kvm/openbios/obj-ppc/../libc/vsprintf.c:388: undefined reference to `_restgpr_22_x' libgcc.a(__divdi3.o): In function `__divdi3': /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:8: undefined reference to `_savegpr_31' /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:26: undefined reference to `_restgpr_31_x' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:4: undefined reference to `_savegpr_26' /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:31: undefined reference to `_restgpr_26_x' make[1]: *** [openbios-qemu.elf] Error 1 make[1]: Leaving directory `/kvm/openbios/obj-ppc' make: *** [build] Error 1
Who can give me some advices?
Cheers,
Zhiyong Wu
On 1/19/10 11:27 AM, Zhiyong Wu wrote:
HI, openbios guys,
Today i compiled openbios on my ppc64 box, encoutered some questions:
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc64 ppc64 ppc64 GNU/Linux
[root@945n03 openbios]# rpm -qa | grep glibc glibc-2.11-2.ppc glibc-2.11-2.ppc64 glibc-devel-2.11-2.ppc glibc-common-2.11-2.ppc glibc-headers-2.11-2.ppc
[root@945n03 openbios]# rpm -qa | grep gcc libgcc-4.4.2-7.fc12.ppc64 gcc-4.4.2-7.fc12.ppc libgcc-4.4.2-7.fc12.ppc gcc-c++-4.4.2-7.fc12.ppc gcc-gfortran-4.4.2-7.fc12.ppc
[root@945n03 openbios]# gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC)
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc64 for ppc ERROR: no powerpc cross-compiler found !
When i run "setarch 32 bash", "switch-arch" can work well, but it fails to run "make"
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc ppc ppc GNU/Linux
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc for ppc Initializing build tree obj-ppc...ok. Creating target Makefile...ok. Creating config files...ok.
Building OpenBIOS for ppc Building...error: /kvm/openbios/obj-ppc/../libc/string.c:499: undefined reference to `_restgpr_31_x' liblibc.a(vsprintf.o): In function `number': /kvm/openbios/obj-ppc/../libc/vsprintf.c:55: undefined reference to `_savegpr_19' /kvm/openbios/obj-ppc/../libc/vsprintf.c:145: undefined reference to `_restgpr_19_x' liblibc.a(vsprintf.o): In function `vsnprintf': /kvm/openbios/obj-ppc/../libc/vsprintf.c:158: undefined reference to `_savegpr_22' /kvm/openbios/obj-ppc/../libc/vsprintf.c:388: undefined reference to `_restgpr_22_x' libgcc.a(__divdi3.o): In function `__divdi3': /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:8: undefined reference to `_savegpr_31' /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:26: undefined reference to `_restgpr_31_x' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:4: undefined reference to `_savegpr_26' /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:31: undefined reference to `_restgpr_26_x' make[1]: *** [openbios-qemu.elf] Error 1 make[1]: Leaving directory `/kvm/openbios/obj-ppc' make: *** [build] Error 1
Who can give me some advices?
I think we need to add this somewhere... :
._savegpr_13: stw r.13, -76(r.12) ._savegpr_14: stw r.14, -72(r.12) ._savegpr_15: stw r.15, -68(r.12) ._savegpr_16: stw r.16, -64(r.12) ._savegpr_17: stw r.17, -60(r.12) ._savegpr_18: stw r.18, -56(r.12) ._savegpr_19: stw r.19, -52(r.12) ._savegpr_20: stw r.20, -48(r.12) ._savegpr_21: stw r.23, -44(r.12) ._savegpr_22: stw r.23, -40(r.12) ._savegpr_23: stw r.23, -36(r.12) ._savegpr_24: stw r.23, -32(r.12) ._savegpr_25: stw r.23, -28(r.12) ._savegpr_26: stw r.23, -24(r.12) ._savegpr_27: stw r.23, -20(r.12) ._savegpr_28: stw r.23, -16(r.12) ._savegpr_29: stw r.23, -12(r.12) ._savegpr_30: stw r.33, -8(r.12) ._savegpr_31: stw r.33, -4(r.12) blr
._restgpr_13: lwz r.13, -76(r.12) ._restgpr_14: lwz r.14, -72(r.12) ._restgpr_15: lwz r.15, -68(r.12) ._restgpr_16: lwz r.16, -64(r.12) ._restgpr_17: lwz r.17, -60(r.12) ._restgpr_18: lwz r.18, -56(r.12) ._restgpr_19: lwz r.19, -52(r.12) ._restgpr_20: lwz r.20, -48(r.12) ._restgpr_21: lwz r.23, -44(r.12) ._restgpr_22: lwz r.23, -40(r.12) ._restgpr_23: lwz r.23, -36(r.12) ._restgpr_24: lwz r.23, -32(r.12) ._restgpr_25: lwz r.23, -28(r.12) ._restgpr_26: lwz r.23, -24(r.12) ._restgpr_27: lwz r.23, -20(r.12) ._restgpr_28: lwz r.23, -16(r.12) ._restgpr_29: lwz r.23, -12(r.12) ._restgpr_30: lwz r.33, -8(r.12) ._restgpr_31: lwz r.33, -4(r.12) blr
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
Stefan
HI, Blue Swirl
Can you give me a help about the issues below?
Thanks ahead.
Cheers,
Zhiyong Wu
---------- Forwarded message ---------- From: Zhiyong Wu zwu.kernel@gmail.com Date: Tue, Jan 19, 2010 at 6:27 PM Subject: Some encountered issues when compiling openbios on a ppc64 host To: openbios@openbios.org Cc: Alexander Graf agraf@suse.de, Zhiyong Wu zwu.kernel@gmail.com
HI, openbios guys,
Today i compiled openbios on my ppc64 box, encoutered some questions:
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc64 ppc64 ppc64 GNU/Linux
[root@945n03 openbios]# rpm -qa | grep glibc glibc-2.11-2.ppc glibc-2.11-2.ppc64 glibc-devel-2.11-2.ppc glibc-common-2.11-2.ppc glibc-headers-2.11-2.ppc
[root@945n03 openbios]# rpm -qa | grep gcc libgcc-4.4.2-7.fc12.ppc64 gcc-4.4.2-7.fc12.ppc libgcc-4.4.2-7.fc12.ppc gcc-c++-4.4.2-7.fc12.ppc gcc-gfortran-4.4.2-7.fc12.ppc
[root@945n03 openbios]# gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC)
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc64 for ppc ERROR: no powerpc cross-compiler found !
When i run "setarch 32 bash", "switch-arch" can work well, but it fails to run "make"
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc ppc ppc GNU/Linux
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc for ppc Initializing build tree obj-ppc...ok. Creating target Makefile...ok. Creating config files...ok.
Building OpenBIOS for ppc Building...error: /kvm/openbios/obj-ppc/../libc/string.c:499: undefined reference to `_restgpr_31_x' liblibc.a(vsprintf.o): In function `number': /kvm/openbios/obj-ppc/../libc/vsprintf.c:55: undefined reference to `_savegpr_19' /kvm/openbios/obj-ppc/../libc/vsprintf.c:145: undefined reference to `_restgpr_19_x' liblibc.a(vsprintf.o): In function `vsnprintf': /kvm/openbios/obj-ppc/../libc/vsprintf.c:158: undefined reference to `_savegpr_22' /kvm/openbios/obj-ppc/../libc/vsprintf.c:388: undefined reference to `_restgpr_22_x' libgcc.a(__divdi3.o): In function `__divdi3': /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:8: undefined reference to `_savegpr_31' /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:26: undefined reference to `_restgpr_31_x' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:4: undefined reference to `_savegpr_26' /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:31: undefined reference to `_restgpr_26_x' make[1]: *** [openbios-qemu.elf] Error 1 make[1]: Leaving directory `/kvm/openbios/obj-ppc' make: *** [build] Error 1
Who can give me some advices?
Cheers,
Zhiyong Wu
On Tue, Jan 19, 2010 at 1:47 PM, Stefan Reinauer stepan@coresystems.de wrote:
On 1/19/10 11:27 AM, Zhiyong Wu wrote:
HI, openbios guys,
Today i compiled openbios on my ppc64 box, encoutered some questions:
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc64 ppc64 ppc64 GNU/Linux
[root@945n03 openbios]# rpm -qa | grep glibc glibc-2.11-2.ppc glibc-2.11-2.ppc64 glibc-devel-2.11-2.ppc glibc-common-2.11-2.ppc glibc-headers-2.11-2.ppc
[root@945n03 openbios]# rpm -qa | grep gcc libgcc-4.4.2-7.fc12.ppc64 gcc-4.4.2-7.fc12.ppc libgcc-4.4.2-7.fc12.ppc gcc-c++-4.4.2-7.fc12.ppc gcc-gfortran-4.4.2-7.fc12.ppc
[root@945n03 openbios]# gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC)
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc64 for ppc ERROR: no powerpc cross-compiler found !
When i run "setarch 32 bash", "switch-arch" can work well, but it fails to run "make"
[root@945n03 openbios]# uname -a Linux 945n03 2.6.31.5-127.fc12.ppc64 #1 SMP Sat Nov 7 20:58:24 EST 2009 ppc ppc ppc GNU/Linux
[root@945n03 openbios]# ./config/scripts/switch-arch ppc Configuring OpenBIOS on ppc for ppc Initializing build tree obj-ppc...ok. Creating target Makefile...ok. Creating config files...ok.
Building OpenBIOS for ppc Building...error: /kvm/openbios/obj-ppc/../libc/string.c:499: undefined reference to `_restgpr_31_x' liblibc.a(vsprintf.o): In function `number': /kvm/openbios/obj-ppc/../libc/vsprintf.c:55: undefined reference to `_savegpr_19' /kvm/openbios/obj-ppc/../libc/vsprintf.c:145: undefined reference to `_restgpr_19_x' liblibc.a(vsprintf.o): In function `vsnprintf': /kvm/openbios/obj-ppc/../libc/vsprintf.c:158: undefined reference to `_savegpr_22' /kvm/openbios/obj-ppc/../libc/vsprintf.c:388: undefined reference to `_restgpr_22_x' libgcc.a(__divdi3.o): In function `__divdi3': /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:8: undefined reference to `_savegpr_31' /kvm/openbios/obj-ppc/../libgcc/__divdi3.c:26: undefined reference to `_restgpr_31_x' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:4: undefined reference to `_savegpr_26' /kvm/openbios/obj-ppc/../libgcc/__udivmoddi4.c:31: undefined reference to `_restgpr_26_x' make[1]: *** [openbios-qemu.elf] Error 1 make[1]: Leaving directory `/kvm/openbios/obj-ppc' make: *** [build] Error 1
Who can give me some advices?
I think we need to add this somewhere... :
._savegpr_13: stw r.13, -76(r.12) ._savegpr_14: stw r.14, -72(r.12) ._savegpr_15: stw r.15, -68(r.12) ._savegpr_16: stw r.16, -64(r.12) ._savegpr_17: stw r.17, -60(r.12) ._savegpr_18: stw r.18, -56(r.12) ._savegpr_19: stw r.19, -52(r.12) ._savegpr_20: stw r.20, -48(r.12) ._savegpr_21: stw r.23, -44(r.12) ._savegpr_22: stw r.23, -40(r.12) ._savegpr_23: stw r.23, -36(r.12) ._savegpr_24: stw r.23, -32(r.12) ._savegpr_25: stw r.23, -28(r.12) ._savegpr_26: stw r.23, -24(r.12) ._savegpr_27: stw r.23, -20(r.12) ._savegpr_28: stw r.23, -16(r.12) ._savegpr_29: stw r.23, -12(r.12) ._savegpr_30: stw r.33, -8(r.12) ._savegpr_31: stw r.33, -4(r.12) blr
._restgpr_13: lwz r.13, -76(r.12) ._restgpr_14: lwz r.14, -72(r.12) ._restgpr_15: lwz r.15, -68(r.12) ._restgpr_16: lwz r.16, -64(r.12) ._restgpr_17: lwz r.17, -60(r.12) ._restgpr_18: lwz r.18, -56(r.12) ._restgpr_19: lwz r.19, -52(r.12) ._restgpr_20: lwz r.20, -48(r.12) ._restgpr_21: lwz r.23, -44(r.12) ._restgpr_22: lwz r.23, -40(r.12) ._restgpr_23: lwz r.23, -36(r.12) ._restgpr_24: lwz r.23, -32(r.12) ._restgpr_25: lwz r.23, -28(r.12) ._restgpr_26: lwz r.23, -24(r.12) ._restgpr_27: lwz r.23, -20(r.12) ._restgpr_28: lwz r.23, -16(r.12) ._restgpr_29: lwz r.23, -12(r.12) ._restgpr_30: lwz r.33, -8(r.12) ._restgpr_31: lwz r.33, -4(r.12) blr
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host. You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux. At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
This is the same approach as taken by Linux.
On 1/19/10 8:00 PM, Blue Swirl wrote:
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host.
libgcc and libc headers have nothing to do with each other. libgcc is part of gcc, and any gcc without libgcc is to be considered an incomplete toolchain.
You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux.
Yes, but if those are built correctly, they still come with libgcc. If they don't, it makes more sense to file a bug report with the toolchain provider than to duplicate parts of the toolchain in openbios.
At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
The administrative burden is higher than using a complete toolchain... Who is supplying gcc without libgcc anyways?
This is the same approach as taken by Linux.
Not a very good argument. libgcc is part of gcc. So there is no reason to duplicate it in any project. This is not some OS dependency like crt0.o but very gcc intrinsic.
Stefan
On Tue, Jan 19, 2010 at 8:59 PM, Stefan Reinauer stepan@openbios.org wrote:
On 1/19/10 8:00 PM, Blue Swirl wrote:
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host.
libgcc and libc headers have nothing to do with each other. libgcc is part of gcc, and any gcc without libgcc is to be considered an incomplete toolchain.
You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux.
Yes, but if those are built correctly, they still come with libgcc. If they don't, it makes more sense to file a bug report with the toolchain provider than to duplicate parts of the toolchain in openbios.
The problem was with older 3.x (maybe early 4.x) series in cross-compile mode, so bug reports may not help.
At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
The administrative burden is higher than using a complete toolchain... Who is supplying gcc without libgcc anyways?
Some numbers: there were just 12 commits regarding libgcc since r4 (!) introduced it in 2006, some of them were generic cleanups.
This is the same approach as taken by Linux.
Not a very good argument. libgcc is part of gcc. So there is no reason to duplicate it in any project. This is not some OS dependency like crt0.o but very gcc intrinsic.
If we decide to only support new GCCs, I guess libgcc support could be dropped. Maybe it's OK after all, for example I don't have the buggy 3.x versions of the cross-compilers anymore. With the 4.2.4 version which I'm using, there is a libgcc.a for all target architectures.
On Wed, Jan 20, 2010 at 5:46 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Tue, Jan 19, 2010 at 8:59 PM, Stefan Reinauer stepan@openbios.org wrote:
On 1/19/10 8:00 PM, Blue Swirl wrote:
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host.
libgcc and libc headers have nothing to do with each other. libgcc is part of gcc, and any gcc without libgcc is to be considered an incomplete toolchain.
You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux.
Yes, but if those are built correctly, they still come with libgcc. If they don't, it makes more sense to file a bug report with the toolchain provider than to duplicate parts of the toolchain in openbios.
The problem was with older 3.x (maybe early 4.x) series in cross-compile mode, so bug reports may not help.
At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
The administrative burden is higher than using a complete toolchain... Who is supplying gcc without libgcc anyways?
Some numbers: there were just 12 commits regarding libgcc since r4 (!) introduced it in 2006, some of them were generic cleanups.
This is the same approach as taken by Linux.
Not a very good argument. libgcc is part of gcc. So there is no reason to duplicate it in any project. This is not some OS dependency like crt0.o but very gcc intrinsic.
If we decide to only support new GCCs, I guess libgcc support could be dropped. Maybe it's OK after all, for example I don't have the buggy 3.x versions of the cross-compilers anymore. With the 4.2.4 version which I'm using, there is a libgcc.a for all target architectures.
This patch would remove libgcc, however PPC needs some work:
LINK openbios-qemu.elf /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o): In function `__eabi': /src/gcc/gcc-4.2.4/obj-amd64/gcc/eabi.S:232: undefined reference to `__init' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4): undefined reference to `_SDA_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x8): undefined reference to `__SDATA_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0xc): undefined reference to `__SBSS_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x10): undefined reference to `_SDA2_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x14): undefined reference to `__SDATA2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x18): undefined reference to `__SBSS2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x1c): undefined reference to `__GOT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x28): undefined reference to `__GOT_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x2c): undefined reference to `__GOT2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x30): undefined reference to `__GOT2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x34): undefined reference to `__FIXUP_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x38): undefined reference to `__FIXUP_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x3c): undefined reference to `__CTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x40): undefined reference to `__CTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x44): undefined reference to `__DTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x48): undefined reference to `__DTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4c): undefined reference to `__EXCEPT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x50): undefined reference to `__EXCEPT_END__' make[1]: *** [openbios-qemu.elf] Error 1
Probably the linker script or some .S files must be tweaked.
Sparc32/64 and amd64 unix versions compile and work.
On Thu, Jan 21, 2010 at 5:30 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Wed, Jan 20, 2010 at 5:46 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Tue, Jan 19, 2010 at 8:59 PM, Stefan Reinauer stepan@openbios.org wrote:
On 1/19/10 8:00 PM, Blue Swirl wrote:
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host.
libgcc and libc headers have nothing to do with each other. libgcc is part of gcc, and any gcc without libgcc is to be considered an incomplete toolchain.
You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux.
Yes, but if those are built correctly, they still come with libgcc. If they don't, it makes more sense to file a bug report with the toolchain provider than to duplicate parts of the toolchain in openbios.
The problem was with older 3.x (maybe early 4.x) series in cross-compile mode, so bug reports may not help.
At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
The administrative burden is higher than using a complete toolchain... Who is supplying gcc without libgcc anyways?
Some numbers: there were just 12 commits regarding libgcc since r4 (!) introduced it in 2006, some of them were generic cleanups.
This is the same approach as taken by Linux.
Not a very good argument. libgcc is part of gcc. So there is no reason to duplicate it in any project. This is not some OS dependency like crt0.o but very gcc intrinsic.
If we decide to only support new GCCs, I guess libgcc support could be dropped. Maybe it's OK after all, for example I don't have the buggy 3.x versions of the cross-compilers anymore. With the 4.2.4 version which I'm using, there is a libgcc.a for all target architectures.
This patch would remove libgcc, however PPC needs some work:
LINK openbios-qemu.elf /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o): In function `__eabi': /src/gcc/gcc-4.2.4/obj-amd64/gcc/eabi.S:232: undefined reference to `__init' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4): undefined reference to `_SDA_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x8): undefined reference to `__SDATA_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0xc): undefined reference to `__SBSS_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x10): undefined reference to `_SDA2_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x14): undefined reference to `__SDATA2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x18): undefined reference to `__SBSS2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x1c): undefined reference to `__GOT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x28): undefined reference to `__GOT_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x2c): undefined reference to `__GOT2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x30): undefined reference to `__GOT2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x34): undefined reference to `__FIXUP_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x38): undefined reference to `__FIXUP_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x3c): undefined reference to `__CTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x40): undefined reference to `__CTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x44): undefined reference to `__DTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x48): undefined reference to `__DTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4c): undefined reference to `__EXCEPT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x50): undefined reference to `__EXCEPT_END__' make[1]: *** [openbios-qemu.elf] Error 1
Probably the linker script or some .S files must be tweaked.
Sparc32/64 and amd64 unix versions compile and work.
The fix was a bit trickier than I thought. First, the PPC problem was that ecrti/n.o was not linked in. I fixed that by switching to gcc for linking (we could have used our local copy of ecrtn.o, but that's no better than local libgcc copy). But using gcc changes all ld parameters to use -Wl, prefix, which gave trouble with the quiet-command macro invocation. Then I had also to add -nostdlib -lgcc because Sparc32/64 didn't succeed with link without them.
Now Sparc32/64 and PPC build and work. I could also build a working Sparc64 image with the native gcc of OpenBSD/Sparc64, version 3.3.5 (propolice). I tested amd64 and x86 unix versions, sparc64 unix seems to be broken ATM.
Before committing this, it would be nice if all developers checked if their build environment still work with the patch and send an ACK.
If someone has problems because of too old build environment and wants to build a new one, I'd recommend trying the following configuration:
sparc-elf-gcc -v Using built-in specs. Target: sparc-elf Configured with: ../configure --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-multilib --enable-languages=c --with-gnu-ld --with-gnu-as --disable-libssp --target=sparc-elf Thread model: single gcc version 4.2.4
sparc64-elf-gcc -v Using built-in specs. Target: sparc64-elf Configured with: ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-ssp : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
powerpc-elf-gcc -v Using built-in specs. Target: powerpc-elf Configured with: ../configure --target=powerpc-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
sparc-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf32_sparc elf64_sparc
sparc64-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf64_sparc elf32_sparc
powerpc-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf32ppc elf32ppclinux elf32ppcsim
Maybe the '-elf' part should be replaced with '-eabi' these days.
On Sat, Jan 23, 2010 at 5:03 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Thu, Jan 21, 2010 at 5:30 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Wed, Jan 20, 2010 at 5:46 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Tue, Jan 19, 2010 at 8:59 PM, Stefan Reinauer stepan@openbios.org wrote:
On 1/19/10 8:00 PM, Blue Swirl wrote:
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host.
libgcc and libc headers have nothing to do with each other. libgcc is part of gcc, and any gcc without libgcc is to be considered an incomplete toolchain.
You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux.
Yes, but if those are built correctly, they still come with libgcc. If they don't, it makes more sense to file a bug report with the toolchain provider than to duplicate parts of the toolchain in openbios.
The problem was with older 3.x (maybe early 4.x) series in cross-compile mode, so bug reports may not help.
At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
The administrative burden is higher than using a complete toolchain... Who is supplying gcc without libgcc anyways?
Some numbers: there were just 12 commits regarding libgcc since r4 (!) introduced it in 2006, some of them were generic cleanups.
This is the same approach as taken by Linux.
Not a very good argument. libgcc is part of gcc. So there is no reason to duplicate it in any project. This is not some OS dependency like crt0.o but very gcc intrinsic.
If we decide to only support new GCCs, I guess libgcc support could be dropped. Maybe it's OK after all, for example I don't have the buggy 3.x versions of the cross-compilers anymore. With the 4.2.4 version which I'm using, there is a libgcc.a for all target architectures.
This patch would remove libgcc, however PPC needs some work:
LINK openbios-qemu.elf /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o): In function `__eabi': /src/gcc/gcc-4.2.4/obj-amd64/gcc/eabi.S:232: undefined reference to `__init' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4): undefined reference to `_SDA_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x8): undefined reference to `__SDATA_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0xc): undefined reference to `__SBSS_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x10): undefined reference to `_SDA2_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x14): undefined reference to `__SDATA2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x18): undefined reference to `__SBSS2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x1c): undefined reference to `__GOT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x28): undefined reference to `__GOT_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x2c): undefined reference to `__GOT2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x30): undefined reference to `__GOT2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x34): undefined reference to `__FIXUP_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x38): undefined reference to `__FIXUP_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x3c): undefined reference to `__CTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x40): undefined reference to `__CTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x44): undefined reference to `__DTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x48): undefined reference to `__DTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4c): undefined reference to `__EXCEPT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x50): undefined reference to `__EXCEPT_END__' make[1]: *** [openbios-qemu.elf] Error 1
Probably the linker script or some .S files must be tweaked.
Sparc32/64 and amd64 unix versions compile and work.
The fix was a bit trickier than I thought. First, the PPC problem was that ecrti/n.o was not linked in. I fixed that by switching to gcc for linking (we could have used our local copy of ecrtn.o, but that's no better than local libgcc copy). But using gcc changes all ld parameters to use -Wl, prefix, which gave trouble with the quiet-command macro invocation. Then I had also to add -nostdlib -lgcc because Sparc32/64 didn't succeed with link without them.
Now Sparc32/64 and PPC build and work. I could also build a working Sparc64 image with the native gcc of OpenBSD/Sparc64, version 3.3.5 (propolice). I tested amd64 and x86 unix versions, sparc64 unix seems to be broken ATM.
Before committing this, it would be nice if all developers checked if their build environment still work with the patch and send an ACK.
If someone has problems because of too old build environment and wants to build a new one, I'd recommend trying the following configuration:
sparc-elf-gcc -v Using built-in specs. Target: sparc-elf Configured with: ../configure --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-multilib --enable-languages=c --with-gnu-ld --with-gnu-as --disable-libssp --target=sparc-elf Thread model: single gcc version 4.2.4
sparc64-elf-gcc -v Using built-in specs. Target: sparc64-elf Configured with: ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-ssp : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
powerpc-elf-gcc -v Using built-in specs. Target: powerpc-elf Configured with: ../configure --target=powerpc-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
sparc-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf32_sparc elf64_sparc
sparc64-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf64_sparc elf32_sparc
powerpc-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf32ppc elf32ppclinux elf32ppcsim
Maybe the '-elf' part should be replaced with '-eabi' these days.
It builds sparc64 here (sparc64-elf cross gcc version 4.4.2 on amd64) unfortunately it does not go beyond first call to __umodti3 This may be related to different convention for global registers but I have not really looked into it.
Blue Swirl wrote:
Now Sparc32/64 and PPC build and work. I could also build a working Sparc64 image with the native gcc of OpenBSD/Sparc64, version 3.3.5 (propolice). I tested amd64 and x86 unix versions, sparc64 unix seems to be broken ATM.
Before committing this, it would be nice if all developers checked if their build environment still work with the patch and send an ACK.
I confirm that applying this patch to r668 breaks something in the Sparc64 build when trying to boot my test Milax image. Without the patch applied I get the output below (which is currently as expected):
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Jan 23 2010 17:06 Type 'help' for detailed information
[sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 7084 bytes entry point is 0x4000 Evaluating FCode... Claim failed!
byte-load: stack overflow, diff 1
byte-load: stack overflow, diff 1
0 >
With the patch applied I get this:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Jan 23 2010 17:10 Type 'help' for detailed information
[sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 7084 bytes entry point is 0x4000 Evaluating FCode... Unhandled Exception 0x0000000000000028 PC = 0x00000000ffd26a2c NPC = 0x00000000ffd26a30 Stopping execution
So yeah, the patch breaks something :(
HTH,
Mark.
On Sat, Jan 23, 2010 at 4:26 PM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Sat, Jan 23, 2010 at 5:03 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Thu, Jan 21, 2010 at 5:30 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Wed, Jan 20, 2010 at 5:46 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Tue, Jan 19, 2010 at 8:59 PM, Stefan Reinauer stepan@openbios.org wrote:
On 1/19/10 8:00 PM, Blue Swirl wrote:
> But frankly, the better solution would be to drop our libgcc copy and use > that of gcc again... It was a design mistake to let our own copy sneak in. > I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host.
libgcc and libc headers have nothing to do with each other. libgcc is part of gcc, and any gcc without libgcc is to be considered an incomplete toolchain.
You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux.
Yes, but if those are built correctly, they still come with libgcc. If they don't, it makes more sense to file a bug report with the toolchain provider than to duplicate parts of the toolchain in openbios.
The problem was with older 3.x (maybe early 4.x) series in cross-compile mode, so bug reports may not help.
At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
The administrative burden is higher than using a complete toolchain... Who is supplying gcc without libgcc anyways?
Some numbers: there were just 12 commits regarding libgcc since r4 (!) introduced it in 2006, some of them were generic cleanups.
This is the same approach as taken by Linux.
Not a very good argument. libgcc is part of gcc. So there is no reason to duplicate it in any project. This is not some OS dependency like crt0.o but very gcc intrinsic.
If we decide to only support new GCCs, I guess libgcc support could be dropped. Maybe it's OK after all, for example I don't have the buggy 3.x versions of the cross-compilers anymore. With the 4.2.4 version which I'm using, there is a libgcc.a for all target architectures.
This patch would remove libgcc, however PPC needs some work:
LINK openbios-qemu.elf /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o): In function `__eabi': /src/gcc/gcc-4.2.4/obj-amd64/gcc/eabi.S:232: undefined reference to `__init' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4): undefined reference to `_SDA_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x8): undefined reference to `__SDATA_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0xc): undefined reference to `__SBSS_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x10): undefined reference to `_SDA2_BASE_' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x14): undefined reference to `__SDATA2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x18): undefined reference to `__SBSS2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x1c): undefined reference to `__GOT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x28): undefined reference to `__GOT_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x2c): undefined reference to `__GOT2_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x30): undefined reference to `__GOT2_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x34): undefined reference to `__FIXUP_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x38): undefined reference to `__FIXUP_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x3c): undefined reference to `__CTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x40): undefined reference to `__CTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x44): undefined reference to `__DTOR_LIST__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x48): undefined reference to `__DTOR_END__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x4c): undefined reference to `__EXCEPT_START__' /usr/local/lib/gcc/powerpc-elf/4.2.4/libgcc.a(eabi.o):(.got2+0x50): undefined reference to `__EXCEPT_END__' make[1]: *** [openbios-qemu.elf] Error 1
Probably the linker script or some .S files must be tweaked.
Sparc32/64 and amd64 unix versions compile and work.
The fix was a bit trickier than I thought. First, the PPC problem was that ecrti/n.o was not linked in. I fixed that by switching to gcc for linking (we could have used our local copy of ecrtn.o, but that's no better than local libgcc copy). But using gcc changes all ld parameters to use -Wl, prefix, which gave trouble with the quiet-command macro invocation. Then I had also to add -nostdlib -lgcc because Sparc32/64 didn't succeed with link without them.
Now Sparc32/64 and PPC build and work. I could also build a working Sparc64 image with the native gcc of OpenBSD/Sparc64, version 3.3.5 (propolice). I tested amd64 and x86 unix versions, sparc64 unix seems to be broken ATM.
Before committing this, it would be nice if all developers checked if their build environment still work with the patch and send an ACK.
If someone has problems because of too old build environment and wants to build a new one, I'd recommend trying the following configuration:
sparc-elf-gcc -v Using built-in specs. Target: sparc-elf Configured with: ../configure --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-multilib --enable-languages=c --with-gnu-ld --with-gnu-as --disable-libssp --target=sparc-elf Thread model: single gcc version 4.2.4
sparc64-elf-gcc -v Using built-in specs. Target: sparc64-elf Configured with: ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-ssp : (reconfigured) ../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
powerpc-elf-gcc -v Using built-in specs. Target: powerpc-elf Configured with: ../configure --target=powerpc-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
sparc-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf32_sparc elf64_sparc
sparc64-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf64_sparc elf32_sparc
powerpc-elf-ld -V GNU ld (GNU Binutils) 2.18 Supported emulations: elf32ppc elf32ppclinux elf32ppcsim
Maybe the '-elf' part should be replaced with '-eabi' these days.
It builds sparc64 here (sparc64-elf cross gcc version 4.4.2 on amd64) unfortunately it does not go beyond first call to __umodti3 This may be related to different convention for global registers but I have not really looked into it.
I didn't add CFLAGS to link line, but adding it doesn't make any difference.
It's also possible that the distributed libgcc is compiled with different set of assumptions. Then I guess we must build our own to be sure.
-
Blue Swirl -
Igor Kovalenko -
Mark Cave-Ayland -
Stefan Reinauer -
Stefan Reinauer -
Zhiyong Wu