[OpenBIOS] cross-pcc compilation issue with GCC 4.5.0

[Blue Swirl]

On 4/26/10, Stefan Reinauer <stepan at openbios.org> wrote:
> On 4/26/10 10:29 PM, Blue Swirl wrote:
>  > On 4/26/10, Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk> wrote:
>  >
>  >> Segher Boessenkool wrote:
>  >>
>  >>
>  >>
>  >>> That patch [which doesn't display in the mail archive btw] seems to remove
>  >>> -print-libgcc-file-name, and uses -lgcc instead -- not such a hot idea?
>  >>>
>  >>> I don't even know how to build OpenBIOS, so I'm not going to fix it,
>  >>>
>  >> sorry.
>  >>
>  >>>
>  >>  If you have a PPC cross-compiler installed, the build is easy:
>  >>
>  >>  ./config/scripts/switch-arch cross-ppc
>  >>  make
>  >>
>  >>  Then copy the resulting binary from obj-ppc/ into your share/qemu
>  >> directory.
>  >>
>  >>
>  >>
>  >>> I'll do my best with directed questions of course :-)
>  >>>
>  >>>
>  >>  Even an idea as to what to look at first would be a great help...
>  >>
>  > I think I can now reproduce the crash, previously I had no problems
>  > which made debugging a bit difficult. I changed gcc's memory model
>  > flag to -mcmodel=medlow and now Milax crashes in __umodti3 like Igor
>  > reported. Perhaps this flag may be different when gcc builds libgcc.
>  >
>  > The problem seems to be that gcc's libgcc divides by zero.
>  > Breakpoint 10, __umodti3 (u=<value optimized out>,
>  >     v=0x0000000000000000fffffffffffffffe) at ../../gcc/libgcc2.c:911
>  > 911     in ../../gcc/libgcc2.c
>  > 11: $i4 = 0x0
>  > 10: $i0 = 0x1
>  > 1: x/i $pc
>  > 0xffd1f980 <__umodti3+952>:     udivx  %i0, %i4, %g1
>  >
>  > Why this doesn't happen with our libgcc? Why it doesn't happen with
>  > -mcmodel=medany? What a puzzle.
>  >
>  > One solution could be to check for division by zero in mudivmod(),
>  > which is where __umodti3 is called from.
>  >
>
>
> Changing the code model  most likely changes the ABI, so it's no wonder
>  it does not work anymore.
>  The same thing happens if your gcc is compiled with a different
>  "regparm" setting than your code.
>
>  This was generally reported to the gcc folks last year but I think
>  nothing has happened since then:
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
>
>  In coreboot we fixed the regparm issue by using a wrapper that converts
>  between the ABIs:
>
>  http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/arch/i386/Makefile.inc#L91
>  http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/lib/gcc.c
>
>  Not sure whether something similar is possible for the code model, too,
>  but it sounds less trivial.
>  So until then the GCC folks' answer is: If your code uses compile time
>  options that change the ABI of your compiler, you need to compile a
>  compiler (well, libgcc) with those options, too. So the simplest way is
>  just not assuming any ABI details if possible and not using CFLAGS that
>  change the default ABI.

I made another test by removing any -mcmodel flags. That makes Milax
not crash, though it doesn't work any better. But then all Linux tests
start to crash.

I would suppose that without -mcmodel, gcc and libgcc would always
match. The remaining suspects (besides general bugginess of gcc or my
hosed configuration) are -m64 (and related as flags) and -fno-builtin.