powerpc/e500: binutils tests [Was: RFC: x86: kill binutils 2.16.x?]

powerpc/e500: binutils tests [Was: RFC: x86: kill binutils 2.16.x?]

[Kyle Moffett]

On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>> The problem is not with the kernel compile itself, but with the 2.12
>> "dssall" binutils test. =C2=A0Basically, recent binutils treats e500 as
>> effectively a separate architecture that happens to share *most* of
>> the opcodes with regular PowerPC. =C2=A0Any opcode which is not understo=
od
>> by the e500 chip is either convert to an equivalent opcode which is
>> understood (IE: lwsync =3D> sync), or failed with an error. =C2=A0This m=
eans
>> that the kernel compile aborts early telling me to upgrade to a newer
>> version of binutils.
>
> $ echo dssall | powerpc-linux-as -many -me500
> $ powerpc-linux-objdump -d a.out | grep 0:
> =C2=A0 0: =C2=A0 7e 00 06 6c =C2=A0 =C2=A0 dssall
> $ powerpc-linux-as --version | head -1
> GNU assembler (GNU Binutils) 2.21.51.20110309
>
> What version of binutils does not work? =C2=A0(I also checked with
> -me500x2, -me500mc, -mspe, and various combinations. =C2=A0lwsync
> is indeed converted to a regular sync (well, "msync") for e500
> and e500x2).

Hmm, something's fishy here.

Just going based on this changeset, the floating point and AltiVec
opcodes are *supposed* to generate hard errors:
  http://sourceware.org/ml/binutils-cvs/2010-06/msg00070.html

Oh... that patch only disables the opcodes if "-many" is not specified.

Aha! The native compiler on my Debian e500 boxes right now is hidden
behind a small wrapper script which removes "-many" and "-Wa,-many"
and generates errors for anything else that isn't "-me500".  My GCC
also excludes the "-many" option when calling the linker directly.

So I think this is only a "local" problem right now, actually, sorry
for the noise and confusion.  If I log into that system and run "echo
dssall | as", I get the expected hard error, and due to the wrapper
scripts in place I get the same error from "echo dssall | as -me500x2
-many"

Unfortunately I still need to have the assembler generate hard errors
when someone tries to natively compile code with AltiVec or
classic-FPU instructions, otherwise I have no way of detecting
unported software at build-time.

Would a patch to make the Altivec "dssall" test conditional on
CONFIG_ALTIVEC be acceptable?  That really is the only test that
causes the kernel compile to fail with the strict wrappers.

Cheers,
Kyle Moffett

Re: powerpc/e500: binutils tests [Was: RFC: x86: kill binutils 2.16.x?]

[Sebastian Andrzej Siewior]

* Kyle Moffett | 2011-03-09 00:22:11 [-0500]:

>On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool
><segher@kernel.crashing.org> wrote:
>>> The problem is not with the kernel compile itself, but with the 2.12
>>> "dssall" binutils test. ??Basically, recent binutils treats e500 as
>>> effectively a separate architecture that happens to share *most* of
>>> the opcodes with regular PowerPC. ??Any opcode which is not understood
>>> by the e500 chip is either convert to an equivalent opcode which is
>>> understood (IE: lwsync => sync), or failed with an error. ??This means
>>> that the kernel compile aborts early telling me to upgrade to a newer
>>> version of binutils.
>>
>> $ echo dssall | powerpc-linux-as -many -me500
>> $ powerpc-linux-objdump -d a.out | grep 0:
>> ?? 0: ?? 7e 00 06 6c ?? ?? dssall
>> $ powerpc-linux-as --version | head -1
>> GNU assembler (GNU Binutils) 2.21.51.20110309
>>
>> What version of binutils does not work? ??(I also checked with
>> -me500x2, -me500mc, -mspe, and various combinations. ??lwsync
>> is indeed converted to a regular sync (well, "msync") for e500
>> and e500x2).
>
>Hmm, something's fishy here.

Did I break anything?
Not sure if mc and x2 are the same thing. One of those e500 thingy has a
the "classic FPU" if I remember correctly.
Anyway, -me500 enables a certain range of opcodes -many enables all of
them (or the remaining few). So without -many this test will fail. The
auto conversion of lwsync => sync or msync should be performed due to
-me500.

>Just going based on this changeset, the floating point and AltiVec
>opcodes are *supposed* to generate hard errors:
>  http://sourceware.org/ml/binutils-cvs/2010-06/msg00070.html
>
>Oh... that patch only disables the opcodes if "-many" is not specified.

To some degree yes. If you specify -me500 -maltivec you can still use
AltiVec opcodes because you enabled them. So for that reason there are
scripts on buildds to prevent passing mcpu to gcc among other things :)

>Cheers,
>Kyle Moffett

Sebastian