On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
