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.