Re: Debian powerpc binary compatibility?
I'm sorry I'm a bit slow in understanding - could you please answer my
On Tue, 21 Sep 2010 21:18:47 +0200
Sebastian Andrzej Siewior <firstname.lastname@example.org> wrote:
> * Sergei Poselenov | 2010-09-21 14:09:24 [+0400]:
> >Hello Sebastian,
> Hi Sergei,
> >BTW, do you know - why the separate target for e500? Is the
> >instruction set for e500 so fundamentally different it needs a
> >special configuration for GCC? Why GCC cannot switch codegeneration
> >at run-time, conditioning on "-mcpu=e500"?
> Because the ABI is different. All you need to the same output as with
> the tripplet you have to specify
> -mcpu=mpc8540 -misel -mfloat-gprs=double
> So with the tripplet you set all this flags as default (unless I
> forgot a switch). -mfloat-gprs changes the ABI from hardfloat to
Probably also -mabi=spe?
> softfloat. That means you can't mix the binaries, they are not longer
I hope I understand now.
You mean I can't build an application in the
powerpc-linux-gcc -o t.o -c t.c -mcpu=mpc8540 -misel -mfloat-gprs=double
powerpc-linux-gcc -o t t.o
In the first step, I built an object with ABI=spe, on the second - I'm
linking the object with libc.so, which is built with the "default"
I can't do this, the objects (.o and libc.so and startup modules
(crt..)) are incompatible, right?
> >Having the separate target looks inconvenient for me - you have to
> >"push" the target to all package, so they wouldn't fail on "configure
> No, you don't have. The dpkg-architecure command on powerpcspe port
> |# dpkg-architecture |grep TYPE
> That means all packages that pass --target usually go for
> DEB_HOST_GNU_TYPE. If you don't specify anything i.e. a simply
> ./configure then it is also correct since it goes for gcc which has
> allready the correct default.
Not sure I understood. I mean the bug list for the powerpcspe
port is full of patches which essentially add the new powerpcspe
configuration target to a lot of packages.
I mean - if you use the traditional "powerpc-linux-gnu" target for
you port with the e500v2 GCC options enabled by one or other way - you
don't need to bother with the new "gnuspe" target support in a lot of
Why the decision to use the gnuspe target?
> >> Yes I can reproduce it on 4.3.
> >This is bad. Does this mean the modern GCC cannot be used for e500
> Some testcases pass, some don't. So yes you may get invalid code. To
> workaround you can disable scheduling in gcc as pointed out in the PR.
> You can probably also avoid the bug if you use -mfloat-gprs=single.
Yes, we are considering to use the -mfloat-gprs=single as a workaround
for our port. Thanks.
> >Mmm, do you mean that you are running the Debian rebuilt with gnuspe
> >GCC and  binutils fix?
> Yes that is the case.
> >Have you considered to fix the "lwsync" problem in kernel? I mean
> >to catch the Illegal Instruction exception and switch the faulted
> >lwsync to sync?
> I've been thinking about it but didn't go for it. The problem with
> that solution is that you are required to emulate the floating point
> code in kernel leaving the "floating unit" untouched. I posted some
> numbers here  and there  and it didn't look good. So the result
> is not worth it.
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520877#48
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575158#57
Understood. Definitely, FP emulation is worse than natural computing.
Thanks a lot for your replies!