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

[Blue Swirl]

On Sat, Jan 23, 2010 at 4:26 PM, Igor Kovalenko
<igor.v.kovalenko at gmail.com> wrote:
> 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.

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.