[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian powerpc binary compatibility?

Hi Sebastian,

I'm sorry I'm a bit slow in understanding - could you please answer my
further questions?

On Tue, 21 Sep 2010 21:18:47 +0200
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> 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
> compatible.

I hope I understand now.
You mean I can't build an application in the
following way:

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"
powerpc ABI.
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
> >--target=powerpc-linux-gnuspe".
> No, you don't have. The dpkg-architecure command on powerpcspe port
> returns:
> |# dpkg-architecture |grep TYPE
> |DEB_BUILD_GNU_TYPE=powerpc-linux-gnuspe
> |DEB_HOST_GNU_TYPE=powerpc-linux-gnuspe
> 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
> >currently?
> 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 [0] 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 [0] and there [1] and it didn't look good. So the result
> is not worth it.
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520877#48
> [1] 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!


> >
> >Regards,
> >Sergei
> Sebastian

Reply to: