lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 9 Mar 2011 00:22:11 -0500
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Segher Boessenkool <segher@...nel.crashing.org>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linuxppc-dev@...ts.ozlabs.org,
	Kyle Moffett <kyle.d.moffett@...ing.com>,
	Kumar Gala <kumar.gala@...escale.com>, sebastian@...akpoint.cc
Subject: powerpc/e500: binutils tests [Was: RFC: x86: kill binutils 2.16.x?]

On Tue, Mar 8, 2011 at 23:39, Segher Boessenkool
<segher@...nel.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.

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ