[OpenBIOS] Some encountered issues when compiling openbios on a ppc64 host

[Igor Kovalenko]

On Sat, Jan 23, 2010 at 5:03 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
> On Thu, Jan 21, 2010 at 5:30 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
>> On Wed, Jan 20, 2010 at 5:46 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
>>> On Tue, Jan 19, 2010 at 8:59 PM, Stefan Reinauer <stepan at 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.

-- 
Kind regards,
Igor V. Kovalenko