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

Re: Debian powerpc binary compatibility?

* 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 softfloat.
That means you can't mix the binaries, they are not longer compatible.

>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.

>> 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.

>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



Reply to: