From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 21 13:45:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 847C2B5A; Mon, 21 Oct 2013 13:45:10 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55893293E; Mon, 21 Oct 2013 13:45:06 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MV000H00RAU4A00@smtpauth3.wiscmail.wisc.edu>; Mon, 21 Oct 2013 07:44:58 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.21.123314, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-69-44.dsl.mdsnwi.sbcglobal.net [76.208.69.44]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MV00008ZREW5V20@smtpauth3.wiscmail.wisc.edu>; Mon, 21 Oct 2013 07:44:58 -0500 (CDT) Message-id: <526521C8.2030003@freebsd.org> Date: Mon, 21 Oct 2013 07:44:56 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: Aleksander , freebsd-hackers@freebsd.org Subject: Re: modyfing cross toolchain compilation References: In-reply-to: X-Enigmail-Version: 1.5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:45:10 -0000 On 10/21/13 01:38, Aleksander wrote: > hello! > > Few days ago, when playing with linux-ppc, I have identified a bug with > PowerPC toolchain. It turns out that PowerPC e500 core is not compilant > with generic ppc ISA - it lacks of 'lwsync' instruction. This instruction > is used in libstdc++.so library, so I need to modify toolchain build > process by adding -me500v2 option, when building libraries. Can you tell > me how to do it, so I can test this potential soluton? > Which core is this? sync (and lwsync) are supposed to be supported on all PowerPC processors, since they are part of Book II and is *supposed* to be transparently interpreted as "sync" if not supported since the L field of the encoding was reserved previous to the introduction of lwsync. So I think your CPU is broken. It seems like GCC does have some hacks for this and may do the right thing via adding some #defines if you set CPUTYPE=8450 in make.conf, but it doesn't look like the relevant glue in config/rs6000 is hooked up for that at present. Without those, since the instruction is supposed to be valid, it will happily compile and assemble it. So an immediate solution is to just change the instruction in libstdc++ to "sync". Longer term, probably the Book-E kernel should trap lwsync illegal instruction faults and interpret them as "sync" (or do nothing, actually, since a trap is as good as a sync) on such broken cores. I doubt this is the last piece of code is userland or ports that assumes that Book-II instructions are valid. This keeps binary compat with compliant cores. We should also fix up GCC so it sets TARGET_E500 if the right CPUTYPE is set so that natively compiled executables don't hit the trap. -Nathan