From owner-freebsd-ppc@freebsd.org Sun Dec 13 17:52:47 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49B94A43B22 for ; Sun, 13 Dec 2015 17:52:47 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28B0818C6 for ; Sun, 13 Dec 2015 17:52:47 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id tBDHqYOR048984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 13 Dec 2015 17:52:40 GMT (envelope-from swills@FreeBSD.org) To: FreeBSD PowerPC ML From: Steve Wills Subject: powerpc64 packages X-Enigmail-Draft-Status: N1110 Message-ID: <566DB063.5080902@FreeBSD.org> Date: Sun, 13 Dec 2015 12:52:35 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Sun, 13 Dec 2015 17:52:40 +0000 (UTC) X-Spam-Status: No, score=2.6 required=4.5 tests=RCVD_ILLEGAL_IP,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.98.7 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 17:52:47 -0000 Hi, I've built ~19k packages for HEAD r290126 powerpc64. To use these, grab and run this shell script: https://people.freebsd.org/~swills/powerpc_pkg_setup.sh then you should be able to install packages from this repo. Note that this took a long time and so these packages are a bit out of date and probably have security issues, so buyer beware. Steve From owner-freebsd-ppc@freebsd.org Sun Dec 13 21:45:35 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87DF9A42AE8 for ; Sun, 13 Dec 2015 21:45:35 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AC8A19AC; Sun, 13 Dec 2015 21:45:35 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-ig0-x236.google.com with SMTP id su19so71723541igc.0; Sun, 13 Dec 2015 13:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=9ANIi5jUXSkIFPqhqG4luZmLLaQHQo9KWPol9ZPS/qM=; b=jnGRFwxrX2m0Yf91vd9LoMkAERAZU26kB4Pd1DRYQcdTS4qjs4Kh3PTk+bI9QFbwZX ky1t8ypU+iaG/vJq/xp1jLb/zcn3Yg6HNbIogPoR631wvfFemVQ/qXA4orFlV3/Q+wSl Z0OxPb4EFXtwo/LQmsexm02WcWPsBedf8nEMvhzcuXTjcSbwakmq0740McS3d6MPtKzK tMKpRQCfwIGEAdY8tl1kTaAzL548RRLV/0zp0ifBJsFg6W18xmnpcVL5YSUWDQ3OQE+Q +Sha4g9NbY6Cfkck4kfJZ+RuGwzoV6SlUExzI4k/I+EaQ0zaLfKNX8WCGapdzRN8KHO5 VzAw== X-Received: by 10.50.103.38 with SMTP id ft6mr11442542igb.60.1450043134826; Sun, 13 Dec 2015 13:45:34 -0800 (PST) Received: from oyster.jbacon.dyndns.org ([64.83.178.251]) by smtp.gmail.com with ESMTPSA id l5sm10877427ioa.17.2015.12.13.13.45.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Dec 2015 13:45:34 -0800 (PST) Subject: Re: powerpc64 packages To: Steve Wills , FreeBSD PowerPC ML References: <566DB063.5080902@FreeBSD.org> From: Jason Bacon Message-ID: <566DE6FC.60009@gmail.com> Date: Sun, 13 Dec 2015 15:45:32 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <566DB063.5080902@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 21:45:35 -0000 That's fabulous, Steve, thanks! Has there been any talk about constructing a package-building farm of some sort for powerpc*? Something like sysutils/condor could be used to coordinate a widely distributed effort. On 12/13/15 11:52, Steve Wills wrote: > Hi, > > I've built ~19k packages for HEAD r290126 powerpc64. > > To use these, grab and run this shell script: > > https://people.freebsd.org/~swills/powerpc_pkg_setup.sh > > then you should be able to install packages from this repo. > > Note that this took a long time and so these packages are a bit out of > date and probably have security issues, so buyer beware. > > Steve > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Mon Dec 14 13:52:58 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3153DA4388D; Mon, 14 Dec 2015 13:52:58 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id E3C021BA8; Mon, 14 Dec 2015 13:52:54 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-141.nat-2.net.cam.ac.uk [131.111.5.141]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 53B76D78FE; Mon, 14 Dec 2015 13:46:27 +0000 (UTC) Date: Mon, 14 Dec 2015 13:46:25 +0000 From: Andrew Turner To: freebsd-ppc@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Testing an Open Firmware interrupt-map patch Message-ID: <20151214134625.79283652@zapp> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 13:52:58 -0000 Hello, I'm looking for testers for a patch to update how we parse the interrupt-map property to follow the ePAPR spec. This property is commonly used with PCIe controllers. The current code doesn't take the parent address size property. When this is non-zero we need to also read these values. This is needed on an arm64 board I have as the interrupt parent has memory-mapped children so needs this to be set. I have a patch at [1] to add this, however would like it if this could be tested on other platforms using this code to check it doesn't break these platforms before I commit it. I welcome feedback on this patch as I would like to commit this soon. Andrew [1] https://reviews.freebsd.org/D4518 From owner-freebsd-ppc@freebsd.org Mon Dec 14 19:47:06 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09562A43F17; Mon, 14 Dec 2015 19:47:06 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB4031EED; Mon, 14 Dec 2015 19:47:05 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id tBEJkhcb076002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2015 19:46:57 GMT (envelope-from swills@FreeBSD.org) Subject: Re: Testing an Open Firmware interrupt-map patch To: Andrew Turner , freebsd-ppc@FreeBSD.org, freebsd-sparc64@FreeBSD.org References: <20151214134625.79283652@zapp> From: Steve Wills Message-ID: <566F1CA4.6010804@FreeBSD.org> Date: Mon, 14 Dec 2015 14:46:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151214134625.79283652@zapp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Mon, 14 Dec 2015 19:46:59 +0000 (UTC) X-Spam-Status: No, score=2.6 required=4.5 tests=RCVD_ILLEGAL_IP,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.98.7 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 19:47:06 -0000 On 12/14/2015 08:46, Andrew Turner wrote: > Hello, > > I'm looking for testers for a patch to update how we parse the > interrupt-map property to follow the ePAPR spec. This property is > commonly used with PCIe controllers. > > The current code doesn't take the parent address size property. When > this is non-zero we need to also read these values. This is needed on > an arm64 board I have as the interrupt parent has memory-mapped > children so needs this to be set. > > I have a patch at [1] to add this, however would like it if this could > be tested on other platforms using this code to check it doesn't break > these platforms before I commit it. > > I welcome feedback on this patch as I would like to commit this soon. Built a kernel with this and it booted fine. Though my kernel is a bit old (r290126) and has another minor change . Is there any other testing you're looking for? Steve From owner-freebsd-ppc@freebsd.org Mon Dec 14 23:47:15 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D90BA479CA; Mon, 14 Dec 2015 23:47:15 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F9EB14D9; Mon, 14 Dec 2015 23:47:14 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id tBENlAvm033004 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Dec 2015 00:47:10 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id tBENlAlf033003; Tue, 15 Dec 2015 00:47:10 +0100 (CET) (envelope-from marius) Date: Tue, 15 Dec 2015 00:47:10 +0100 From: Marius Strobl To: Andrew Turner Cc: freebsd-ppc@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: Testing an Open Firmware interrupt-map patch Message-ID: <20151214234710.GA32903@alchemy.franken.de> References: <20151214134625.79283652@zapp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151214134625.79283652@zapp> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Tue, 15 Dec 2015 00:47:10 +0100 (CET) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 23:47:15 -0000 On Mon, Dec 14, 2015 at 01:46:25PM +0000, Andrew Turner wrote: > Hello, > > I'm looking for testers for a patch to update how we parse the > interrupt-map property to follow the ePAPR spec. This property is > commonly used with PCIe controllers. > > The current code doesn't take the parent address size property. When > this is non-zero we need to also read these values. This is needed on > an arm64 board I have as the interrupt parent has memory-mapped > children so needs this to be set. > > I have a patch at [1] to add this, however would like it if this could > be tested on other platforms using this code to check it doesn't break > these platforms before I commit it. + "#address-cells", &paddrsz, sizeof(paddrsz)) == -1) + paddrsz = 0; /* default */ According to IEEE 1275-1994 (page 110) the default in case of a "#address-cells" property is 2 (see also ofw_bus_setup_iinfo()), with the latter also being known as the correct default value for sparc64 machines. In any case, this will have quite an impact on the offset calculation on sparc64 machines for e. g. EBusses beneath PCI busses (which use 3 address cells there) and, thus, most likely will cause havoc. Maybe the parent unit address should be only taken into account on platforms using interrupt parents? Marius From owner-freebsd-ppc@freebsd.org Tue Dec 15 00:29:29 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86110A44B4B; Tue, 15 Dec 2015 00:29:29 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 587541D21; Tue, 15 Dec 2015 00:29:29 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (bcdcce0d.skybroadband.com [188.220.206.13]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 43013D78FE; Tue, 15 Dec 2015 00:28:54 +0000 (UTC) Date: Tue, 15 Dec 2015 00:28:30 +0000 From: Andrew Turner To: Marius Strobl Cc: freebsd-sparc64@FreeBSD.org, freebsd-ppc@FreeBSD.org Subject: Re: Testing an Open Firmware interrupt-map patch Message-ID: <20151215002830.2531673d@zapp> In-Reply-To: <20151214234710.GA32903@alchemy.franken.de> References: <20151214134625.79283652@zapp> <20151214234710.GA32903@alchemy.franken.de> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 00:29:29 -0000 On Tue, 15 Dec 2015 00:47:10 +0100 Marius Strobl wrote: > On Mon, Dec 14, 2015 at 01:46:25PM +0000, Andrew Turner wrote: > > Hello, > > > > I'm looking for testers for a patch to update how we parse the > > interrupt-map property to follow the ePAPR spec. This property is > > commonly used with PCIe controllers. > > > > The current code doesn't take the parent address size property. When > > this is non-zero we need to also read these values. This is needed > > on an arm64 board I have as the interrupt parent has memory-mapped > > children so needs this to be set. > > > > I have a patch at [1] to add this, however would like it if this > > could be tested on other platforms using this code to check it > > doesn't break these platforms before I commit it. > > + "#address-cells", &paddrsz, sizeof(paddrsz)) == > -1) > + paddrsz = 0; /* default */ > > According to IEEE 1275-1994 (page 110) the default in case of a > "#address-cells" property is 2 (see also ofw_bus_setup_iinfo()), > with the latter also being known as the correct default value > for sparc64 machines. However both Linux and NetBSD have similar code, both assume a missing interrupt-parent #address-size property the correct value is 0. > In any case, this will have quite an impact on the offset > calculation on sparc64 machines for e. g. EBusses beneath PCI > busses (which use 3 address cells there) and, thus, most likely > will cause havoc. Maybe the parent unit address should be only > taken into account on platforms using interrupt parents? It would seem there is a difference between the encoding on Sparc64 and ePAPR. Using the the parent #address-size may lead to incorrect parsing on Sparc64, as such I will disable it there. Andrew From owner-freebsd-ppc@freebsd.org Tue Dec 15 03:34:44 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E9FFA47F8A for ; Tue, 15 Dec 2015 03:34:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2400C1E7B for ; Tue, 15 Dec 2015 03:34:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28371 invoked from network); 15 Dec 2015 03:34:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 03:34:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 14 Dec 2015 22:34:35 -0500 (EST) Received: (qmail 5775 invoked from network); 15 Dec 2015 03:34:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 03:34:35 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 304B31C43BA; Mon, 14 Dec 2015 19:34:30 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT lib32/libc.so.7 _init dies (powerpc64-gcc/WITH_LIBCPLUSPLUS based): details of how Message-Id: <3FCCD60E-E5EB-4BB4-8C4A-767AE93C8945@dsl-only.net> Date: Mon, 14 Dec 2015 19:34:35 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 03:34:44 -0000 If I avoid use of lib32 I can use powerpc64-gcc on a powerpc64 PowerMac = G5 to build and then install kernel and world, including WITH_BOOT=3D. = Rebooting and running works fine. WITH_LIB32=3D does build and install = as well --but it does not run fine. After the reboot compiling/linking the below source code with -m32 via = powerpc64-gcc running the a.out has lib32/libc.so.7 die in libc.so.7's = _init: > # more main.c > int main() > { > return 0; > } > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped > Reading symbols from a.out...(no debugging symbols found)...done. > (gdb) start > Temporary breakpoint 1 at 0x1800684 > Starting program: /root/c_tests/a.out=20 >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x41867ee0 in _init () from /usr/lib32/libc.so.7 > (gdb) x/20i 0x41867ecc > 0x41867ecc <_init>: stwu r1,-16(r1) > 0x41867ed0 <_init+4>: mflr r0 > 0x41867ed4 <_init+8>: stw r31,12(r1) > 0x41867ed8 <_init+12>: stw r0,20(r1) > 0x41867edc <_init+16>: mr r31,r1 > =3D> 0x41867ee0 <_init+20>: lwz r3,-11432(r30) > 0x41867ee4 <_init+24>: lwz r9,0(r3) > 0x41867ee8 <_init+28>: cmpwi cr7,r9,0 > 0x41867eec <_init+32>: beq cr7,0x41867f04 <_init+56> . . . so r30 is as it was at the indirect call from objlist_call_init . = . . > (gdb) x/150i objlist_call_init > 0x41814c74 : stwu r1,-64(r1) > 0x41814c78 : mflr r0 > 0x41814c7c : bl 0x4183bb58 > 0x41814c80 : li r8,0 > 0x41814c84 : stw r30,56(r1) > 0x41814c88 : mflr r30 > . . . > 0x41814d88 : bl 0x418131b0 = > 0x41814d8c : lwz r9,4(r28) > 0x41814d90 : lwz r5,256(r9) > 0x41814d94 : mtctr r5 > 0x41814d98 : bctrl > . . . . . . which established r30=3D=3D0x4183bb58+4 (from the bl prior to the = mflr above). . . > (gdb) x/4i 0x4183bb58 > 0x4183bb58: blrl > 0x4183bb5c <_SDA_BASE_>: .long 0x2b3f8 > 0x4183bb60 <_SDA_BASE_+4>: .long 0x0 > 0x4183bb64 <_SDA_BASE_+8>: .long 0x0 > (gdb) info registers > r0 0x41814d9c 1098993052 > r1 0xffffd730 4294956848 > r2 0x41835508 1099126024 > r3 0x0 0 > r4 0x4183c4dc 1099154652 > r5 0x41867ecc 1099333324 > r6 0x0 0 > r7 0x1000 4096 > r8 0x0 0 > r9 0x0 0 > r10 0x4182f200 1099100672 > r11 0xffffd780 4294956928 > r12 0x41814d58 1098992984 > r13 0x0 0 > r14 0x6474e552 1685382482 > r15 0x6474e551 1685382481 > r16 0x2 2 > r17 0x4183b48c 1099150476 > r18 0x4182f000 1099100160 > r19 0x0 0 > r20 0x1 1 > r21 0x0 0 > r22 0x4183bb90 1099152272 > r23 0xffffd788 4294956936 > r24 0x4183bbb4 1099152308 > r25 0x4183bbc8 1099152328 > r26 0x4183bbcc 1099152332 > r27 0x4183bbec 1099152364 > r28 0x41830050 1099104336 > r29 0x0 0 > r30 0x4183bb5c 1099152220 > r31 0xffffd730 4294956848 > pc 0x41867ee0 0x41867ee0 <_init+20> > msr > cr 0x28000482 671089794 > lr 0x41814d9c 0x41814d9c > ctr 0x41867ecc 1099333324 > xer 0x20000000 536870912 > (gdb) x 0x4183bb5c-11432 > 0x41838eb4: Cannot access memory at address 0x41838eb4 That subtraction being from "lwz r3,-11432(r30)". My guess would be that the r30 value and the offset in _init are not = matched up correctly. I've not tracked down where the _init code at and = after _init+20 comes from (i.e., _init at and after 0x41867ee0). Context details, ignore unless you care: (tabs and such probably not preserved) > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed = Dec 9 09:15:33 PST 2015 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc 1100091 1100091 > # more ~/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host=20 > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc > TARGET_ARCH=3Dpowerpc64 > WITHOUT_CROSS_COMPILER=3D > # > # 1 thing that fails to build if attempted: > WITHOUT_CLANG_EXTRAS=3D > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_LIB32=3D > WITH_BOOT=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > # > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > #CFLAGS+=3D -DELF_VERBOSE > # > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > # > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > # > DEPFLAGS+=3D -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/. = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/. = -I/usr/include/c++/v1/. > # > CFLAGS+=3D -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib/. = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib/. > # > LDFLAGS+=3D -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib/. = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib/. > # > CXXFLAGS+=3D -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/. = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/. = -std=3Dgnu++11 > # > CXXFLAGS+=3D -I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # svnlite diff /usr/src/ > Index: /usr/src/sys/boot/ofw/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/ofw/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/powerpc/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/powerpc/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,6 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/uboot/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/uboot/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 291891) > +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy) > @@ -110,6 +110,23 @@ > * Assume that interrupt are disabled at this point, or > * SPRG1-3 could be trashed > */ > +#if defined(AIM) && defined(__powerpc64__) > +/* HACK: PowerMac G5 specific code to avoid demonstrated hangs in > + * the early boot time frame. > + * This would need a live test for PowerMac vs. not in order > + * to remove HACK status. > + */ > + if (1) > + __asm __volatile("mfsprg0 %0\n\t" > + "mtsprg1 %1\n\t" > + "mtsprg2 %2\n\t" > + "mtsprg3 %3\n\t" > + : "=3D&r"(ofw_sprg0_save) > + : "r"(ofmsr[2]), > + "r"(ofmsr[3]), > + "r"(ofmsr[4])); > + else > +#endif > __asm __volatile("mfsprg0 %0\n\t" > "mtsprg0 %1\n\t" > "mtsprg1 %2\n\t" > # svnlite diff /usr/ports/ > Index: = /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 = (revision 403711) > +++ /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 = (working copy) > @@ -1,5 +1,5 @@ > ---- gcc/config/rs6000/freebsd64.h 2015-11-28 09:06:13.019999000 = -0800 > -+++ gcc/config/rs6000/freebsd64.h 2015-11-28 09:16:10.459373000 = -0800 > +--- gcc/config/rs6000/freebsd64.h.orig 2015-01-05 = 04:33:28.000000000 -0800 > ++++ gcc/config/rs6000/freebsd64.h 2015-12-09 00:14:28.520684000 = -0800 > @@ -65,6 +65,13 @@ > #define INVALID_64BIT "-m%s not supported in this configuration" > #define INVALID_32BIT INVALID_64BIT > @@ -27,3 +27,12 @@ > if (rs6000_isa_flags & OPTION_MASK_EABI) \ > { \ > rs6000_isa_flags &=3D ~OPTION_MASK_EABI; \ > +@@ -304,7 +317,7 @@ > +=20 > + /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > + #undef WCHAR_TYPE > +-#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > ++#define WCHAR_TYPE "int" > + #undef WCHAR_TYPE_SIZE > + #define WCHAR_TYPE_SIZE 32 > +=20 powerpc64-gcc's misclassification of the base type for L". . ." notation = does need to be patched. Otherwise building lib32 fails for type errors. = That is what the above is for. Having a powerpc64 self-host powerpc64-gcc has a work around of copying = 6 files to the right names/places near the end of the powerpc64-gcc = build and continuing it from that state. (I've not made a patch to deal = with powerpc64-gcc not really being a cross-compiler context for this.) > # ls -l /usr/lib/libstdc+* > lrwxr-xr-x 1 root wheel 8 Dec 5 05:41 /usr/lib/libstdc++.a -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Dec 5 05:41 /usr/lib/libstdc++.so -> = libc++.so > # ls -l /usr/bin/g[c+][c+] > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/g++ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc These symbolic links deal with some environment-forced/automatic = references to what would otherwise be to missing files. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Dec 15 07:07:00 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E2DBA479CA for ; Tue, 15 Dec 2015 07:07:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23FFB176B for ; Tue, 15 Dec 2015 07:06:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3385 invoked from network); 15 Dec 2015 07:06:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 07:06:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 15 Dec 2015 02:06:57 -0500 (EST) Received: (qmail 18451 invoked from network); 15 Dec 2015 07:06:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 07:06:56 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E3A6C1C43AE; Mon, 14 Dec 2015 23:06:45 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1 Message-Id: <894D2513-6DE7-4E31-87A5-0529ECDF336C@dsl-only.net> Date: Mon, 14 Dec 2015 23:06:51 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 07:07:00 -0000 # more main.c int main() { return 0; } # ls -l `which cc` -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc # cc --version FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 Target: powerpc64-unknown-freebsd11.0 Thread model: posix # cc -m32 -mcpu=3Dpowerpc main.c # file a.out a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped By contrast powerpc64-gcc binds the a.out produced to = /libexec/ld-elf32.so.1 instead: # ls -l `which gcc` lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc # gcc --version gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is = NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. # gcc -m32 -mcpu=3Dpowerpc main.c # file a.out a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped Context details: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed Dec = 9 09:15:33 PST 2015 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc 1100091 1100091 # pkg info powerpc64-gcc powerpc64-gcc-5.2.0_1 Name : powerpc64-gcc Version : 5.2.0_1 Installed on : Wed Dec 9 02:18:14 2015 PST Origin : devel/powerpc64-gcc Architecture : freebsd:11:powerpc:64 Prefix : /usr/local Categories : devel . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Dec 15 10:15:59 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 547B7A44A6E; Tue, 15 Dec 2015 10:15:59 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 1EDFE1CAD; Tue, 15 Dec 2015 10:15:58 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 3565E1E2245C; Tue, 15 Dec 2015 11:13:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1450174424; bh=tIBI6xa+PcBog6Ak1Rv0U//gwyHPavMAzn20mP2LFWs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kZi7lur8+knMDIVajouokm/bxvPp1TwrJDQYws1VyeoSgjRlI/ZFP60IcYHbtFj23 GyjfwniEIoSVHQi7/ESONiebH5oz8YBCW91svc35QxytDzjdqBi1oCLa5I7GDwwIiJ JVA5x6C4Sd5JPG4ujrHC+uhvSRNxjTATy1gY/1bg= Date: Tue, 15 Dec 2015 11:13:44 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Subject: Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1 Message-ID: <20151215101344.GA28748@vlakno.cz> References: <894D2513-6DE7-4E31-87A5-0529ECDF336C@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <894D2513-6DE7-4E31-87A5-0529ECDF336C@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 10:15:59 -0000 Check the code in tools/clang/lib/Driver/Tools.cpp. That specifies the /libexec/ld-elf.so.1. On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: > # more main.c > int main() > { > return 0; > } > > > > # ls -l `which cc` > -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc > > # cc --version > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > Target: powerpc64-unknown-freebsd11.0 > Thread model: posix > > # cc -m32 -mcpu=powerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped > > > > By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1 instead: > > # ls -l `which gcc` > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > > # gcc --version > gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > # gcc -m32 -mcpu=powerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped > > > Context details: > > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed Dec 9 09:15:33 PST 2015 root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc 1100091 1100091 > > # pkg info powerpc64-gcc > powerpc64-gcc-5.2.0_1 > Name : powerpc64-gcc > Version : 5.2.0_1 > Installed on : Wed Dec 9 02:18:14 2015 PST > Origin : devel/powerpc64-gcc > Architecture : freebsd:11:powerpc:64 > Prefix : /usr/local > Categories : devel > . . . > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Tue Dec 15 12:36:51 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38E75A448E7; Tue, 15 Dec 2015 12:36:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D83481F08; Tue, 15 Dec 2015 12:36:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tBFCaef7016947 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Dec 2015 14:36:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBFCaef7016947 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBFCaefc016946; Tue, 15 Dec 2015 14:36:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Dec 2015 14:36:40 +0200 From: Konstantin Belousov To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Subject: Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1 Message-ID: <20151215123640.GG3625@kib.kiev.ua> References: <894D2513-6DE7-4E31-87A5-0529ECDF336C@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <894D2513-6DE7-4E31-87A5-0529ECDF336C@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 12:36:51 -0000 On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: > # more main.c > int main() > { > return 0; > } > > > > # ls -l `which cc` > -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc > > # cc --version > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > Target: powerpc64-unknown-freebsd11.0 > Thread model: posix > > # cc -m32 -mcpu=powerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped > > > > By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1 instead: > > # ls -l `which gcc` > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > > # gcc --version > gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > # gcc -m32 -mcpu=powerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped > This is a bug in gcc, most likely in the spec file. All FreeBSD ABIs use either /libexec/ld-elf.so.1 or (for older versions) /usr/libexec/ld-elf.so.1. > > Context details: > > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed Dec 9 09:15:33 PST 2015 root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc 1100091 1100091 > > # pkg info powerpc64-gcc > powerpc64-gcc-5.2.0_1 > Name : powerpc64-gcc > Version : 5.2.0_1 > Installed on : Wed Dec 9 02:18:14 2015 PST > Origin : devel/powerpc64-gcc > Architecture : freebsd:11:powerpc:64 > Prefix : /usr/local > Categories : devel > . . . > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Tue Dec 15 18:15:04 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2BA9A43D71 for ; Tue, 15 Dec 2015 18:15:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86FDC1970 for ; Tue, 15 Dec 2015 18:15:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21384 invoked from network); 15 Dec 2015 18:15:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 18:15:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 15 Dec 2015 13:15:04 -0500 (EST) Received: (qmail 25644 invoked from network); 15 Dec 2015 18:15:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 18:15:03 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 344D11C43AE; Tue, 15 Dec 2015 10:14:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1 From: Mark Millard In-Reply-To: <20151215123640.GG3625@kib.kiev.ua> Date: Tue, 15 Dec 2015 10:15:01 -0800 Cc: Konstantin Belousov , Roman Divacky Content-Transfer-Encoding: quoted-printable Message-Id: <0FA30C32-6F18-43CC-A2F7-3E424FF59021@dsl-only.net> References: <894D2513-6DE7-4E31-87A5-0529ECDF336C@dsl-only.net> <20151215123640.GG3625@kib.kiev.ua> To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 18:15:04 -0000 On 2015-Dec-15, at 4:36 AM, Konstantin Belousov = wrote: > On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: > . . . >> By contrast powerpc64-gcc binds the a.out produced to = /libexec/ld-elf32.so.1 instead: >>=20 >> # ls -l `which gcc` >> lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >>=20 >> # gcc --version >> gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There = is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >>=20 >> # gcc -m32 -mcpu=3Dpowerpc main.c >> # file a.out >> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped >=20 > This is a bug in gcc, most likely in the spec file. All FreeBSD > ABIs use either /libexec/ld-elf.so.1 or (for older versions) > /usr/libexec/ld-elf.so.1. If 32 bit code on powerpc64 is supposed to use /libexec/ld-elf.so.1 just = like the 64 bit code is supposed to then. . . Looks like lang/gcc49 has the same -m32 -mcpu-powerpc ld-elf32.so.1 = problem as powerpc64-gcc: # grep ld-elf = /usr/obj/portswork/usr/ports/lang/gcc49/work/gcc-4.9-20151202/gcc/config/r= s6000/freebsd64.h #define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1" #define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1" # grep ld-elf = /usr/obj/portswork/usr/ports/lang/gcc49/work/stage/usr/local/lib/gcc49/gcc= /powerpc64-portbld-freebsd11.0/4.9.4/plugin/include/config/rs6000/freebsd6= 4.h #define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1" #define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1" Since powerrpc64-gcc is a variant build of gcc5, lang/gcc5 likely has = the problem too. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Dec-15, at 4:36 AM, Konstantin Belousov = wrote: On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: > # more main.c > int main() > { > return 0; > } >=20 >=20 >=20 > # ls -l `which cc` > -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc >=20 > # cc --version > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > Target: powerpc64-unknown-freebsd11.0 > Thread model: posix >=20 > # cc -m32 -mcpu=3Dpowerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped >=20 >=20 >=20 > By contrast powerpc64-gcc binds the a.out produced to = /libexec/ld-elf32.so.1 instead: >=20 > # ls -l `which gcc` > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >=20 > # gcc --version > gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # gcc -m32 -mcpu=3Dpowerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped >=20 This is a bug in gcc, most likely in the spec file. All FreeBSD ABIs use either /libexec/ld-elf.so.1 or (for older versions) /usr/libexec/ld-elf.so.1. >=20 > Context details: >=20 > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed = Dec 9 09:15:33 PST 2015 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc 1100091 1100091 >=20 > # pkg info powerpc64-gcc > powerpc64-gcc-5.2.0_1 > Name : powerpc64-gcc > Version : 5.2.0_1 > Installed on : Wed Dec 9 02:18:14 2015 PST > Origin : devel/powerpc64-gcc > Architecture : freebsd:11:powerpc:64 > Prefix : /usr/local > Categories : devel > . . . >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Tue Dec 15 18:37:36 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5576A48D4E; Tue, 15 Dec 2015 18:37:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0451778; Tue, 15 Dec 2015 18:37:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 82A2A1CF6; Tue, 15 Dec 2015 18:37:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 3BF10175CA; Tue, 15 Dec 2015 18:37:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id iNV_XT0bKSDH; Tue, 15 Dec 2015 18:37:33 +0000 (UTC) Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com D0CDB175C4 To: Mark Millard , "Simon J. Gerraty" References: <2426.1449521335@chaos> <56675638.5010904@FreeBSD.org> Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current From: Bryan Drewery Organization: FreeBSD Message-ID: <56705DEB.2030004@FreeBSD.org> Date: Tue, 15 Dec 2015 10:37:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56675638.5010904@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 18:37:36 -0000 On 12/8/15 2:14 PM, Bryan Drewery wrote: > On 12/7/15 1:33 PM, Mark Millard wrote: >> >>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote: >>> >>> Mark Millard wrote: >>>> My guess is that it is picking up the >>>> >>>> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain >>> >>> You should use ?= if you want this to work. >>> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked >>> in the environment of a sub-make. >>> >>> By using = above, you break that. >> >> That presumes that MAKEOBJDIRPREFIX has not been assigned a default value before the SRC_ENV_CONF file has been included the first time. If MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and the wrong value would be used. >> >> I believe that the following trace shows that such an assignment of a default value does happen first, making ?= not work either. >> >> >> >> /usr/src/Makefile (head/Makefile 29160) has >> >>> MAKEOBJDIRPREFIX?= /usr/obj >> >> at line 145 (used when it is not using targets/Makefile from the relevant .if/.else/.endif). >> >> Line 105 has .include and there no others before the above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), which in turns includes bsd.mkopt.mk (only). That in turn includes nothing else. So these files and only these files are the involved files before that assignment as far as I can tell. >> >> None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not happened yet when >> >>> MAKEOBJDIRPREFIX?= /usr/obj >> >> is executed. >> >> So, if I understand right, MAKEOBJDIRPREFIX is already defined before the code >> >>> SRC_ENV_CONF?= /etc/src-env.conf >>> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_) >>> .-include "${SRC_ENV_CONF}" >>> _src_env_conf_included_: .NOTMAIN >>> .endif >> >> is executed and so using ?= would not be effective in the included file. >> >> Did I miss something? > > > Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it > as being in line 0. > > Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or > src.conf if you are not using any of the meta mode features (all off by > default). > Clarification: We *could* support this but it does not work today. We can use .OBJDIR to force using a MAKEOBJDIRPREFIX from make.conf but only if we also force creating the directory as well. Getting this all right just ends up falling into the new auto.obj.mk territory anyhow. I do want to expand that to the default build, which would allow setting MAKEOBJDIRPREFIX in src-env.conf. -- Regards, Bryan Drewery From owner-freebsd-ppc@freebsd.org Tue Dec 15 18:48:22 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4991A48637 for ; Tue, 15 Dec 2015 18:48:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 985C514C1 for ; Tue, 15 Dec 2015 18:48:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5154 invoked from network); 15 Dec 2015 18:48:26 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 18:48:26 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 15 Dec 2015 13:48:20 -0500 (EST) Received: (qmail 9098 invoked from network); 15 Dec 2015 18:48:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 18:48:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 623DF1C43BC; Tue, 15 Dec 2015 10:48:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: powerpc64: powerpc64-gcc, gcc49, gcc5 bind -m32 -mcpu=powerpc a.out to /libexec/ld-elf32.so.1 instead of /libexec/ld-elf.so.1 From: Mark Millard Date: Tue, 15 Dec 2015 10:48:20 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <436094AA-A35B-4586-8B88-38B8E31A009E@dsl-only.net> References: <0FA30C32-6F18-43CC-A2F7-3E424FF59021@dsl-only.net> To: freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 18:48:22 -0000 [This is mostly a re-titling of an earlier freebsd-pcc/freebsd-toolchain = message to correctly identify the problem. I also added the = freebsd-ports list and some content.] On 2015-Dec-15, at 4:36 AM, Konstantin Belousov = wrote: > On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: >=20 > # more main.c > int main() > { > return 0; > } >=20 > . . . >> By contrast powerpc64-gcc binds the a.out produced to = /libexec/ld-elf32.so.1 instead: >>=20 >> # ls -l `which gcc` >> lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >>=20 >> # gcc --version >> gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There = is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >>=20 >> # gcc -m32 -mcpu=3Dpowerpc main.c >> # file a.out >> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped >=20 > This is a bug in gcc, most likely in the spec file. All FreeBSD > ABIs use either /libexec/ld-elf.so.1 or (for older versions) > /usr/libexec/ld-elf.so.1. If 32 bit code on powerpc64 is supposed to use /libexec/ld-elf.so.1 just = like the 64 bit code is supposed to then. . . Looks like lang/gcc49 has the same -m32 -mcpu=3Dpowerpc ld-elf32.so.1 = problem as powerpc64-gcc: # grep ld-elf = /usr/obj/portswork/usr/ports/lang/gcc49/work/gcc-4.9-20151202/gcc/config/r= s6000/freebsd64.h #define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1" #define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1" # grep ld-elf = /usr/obj/portswork/usr/ports/lang/gcc49/work/stage/usr/local/lib/gcc49/gcc= /powerpc64-portbld-freebsd11.0/4.9.4/plugin/include/config/rs6000/freebsd6= 4.h #define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1" #define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1" Since powerpc64-gcc is a variant build of gcc5 and also has the above = sort of freebsd64.h content, lang/gcc5 likely has the problem too. (By contrast the powerpc64 system clang (3.7) binds its -m32 = -mcpu-powerpc a.out output file to /libexec/ld-elf.so.1 .) Just for reference, my new patch-gcc-freebsd-powerpc64 variant looks = like the following (tabs likely not preserved): # svnlite diff /usr/ports/devel/powerpc64-gcc Index: /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 = (revision 403711) +++ /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 = (working copy) @@ -1,5 +1,5 @@ ---- gcc/config/rs6000/freebsd64.h 2015-11-28 09:06:13.019999000 = -0800 -+++ gcc/config/rs6000/freebsd64.h 2015-11-28 09:16:10.459373000 = -0800 +--- freebsd64.h.orig 2015-01-05 04:33:28.000000000 -0800 ++++ freebsd64.h 2015-12-15 09:52:34.634200000 -0800 @@ -65,6 +65,13 @@ #define INVALID_64BIT "-m%s not supported in this configuration" #define INVALID_32BIT INVALID_64BIT @@ -27,3 +27,21 @@ if (rs6000_isa_flags & OPTION_MASK_EABI) \ { \ rs6000_isa_flags &=3D ~OPTION_MASK_EABI; \ +@@ -154,7 +167,7 @@ + { "link_os_freebsd_spec32", LINK_OS_FREEBSD_SPEC32 }, = \ + { "link_os_freebsd_spec64", LINK_OS_FREEBSD_SPEC64 }, +=20 +-#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1" ++#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf.so.1" + #define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1" +=20 + #define LINK_OS_FREEBSD_SPEC_DEF32 "\ +@@ -304,7 +317,7 @@ +=20 + /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ + #undef WCHAR_TYPE +-#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") ++#define WCHAR_TYPE "int" + #undef WCHAR_TYPE_SIZE + #define WCHAR_TYPE_SIZE 32 +=20 The same sort of changes should apply to gcc49 and gcc5. The WCHAR_TYPE change fixes the powerpc (non-64) base type used for = notations like L". . ." to match FreeBSD's powerpc/powerpc64 context. = Otherwise lib32 in buildworld gets compile errors from the type = mismatches --and lots of extra warnings as well. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Dec-15, at 4:36 AM, Konstantin Belousov = wrote: On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: > # more main.c > int main() > { > return 0; > } >=20 >=20 >=20 > # ls -l `which cc` > -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc >=20 > # cc --version > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > Target: powerpc64-unknown-freebsd11.0 > Thread model: posix >=20 > # cc -m32 -mcpu=3Dpowerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped >=20 >=20 >=20 > By contrast powerpc64-gcc binds the a.out produced to = /libexec/ld-elf32.so.1 instead: >=20 > # ls -l `which gcc` > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >=20 > # gcc --version > gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # gcc -m32 -mcpu=3Dpowerpc main.c > # file a.out > a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, = FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped >=20 This is a bug in gcc, most likely in the spec file. All FreeBSD ABIs use either /libexec/ld-elf.so.1 or (for older versions) /usr/libexec/ld-elf.so.1. >=20 > Context details: >=20 > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed = Dec 9 09:15:33 PST 2015 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc 1100091 1100091 >=20 > # pkg info powerpc64-gcc > powerpc64-gcc-5.2.0_1 > Name : powerpc64-gcc > Version : 5.2.0_1 > Installed on : Wed Dec 9 02:18:14 2015 PST > Origin : devel/powerpc64-gcc > Architecture : freebsd:11:powerpc:64 > Prefix : /usr/local > Categories : devel > . . . >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Tue Dec 15 18:54:06 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01459A489A7 for ; Tue, 15 Dec 2015 18:54:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B95991987 for ; Tue, 15 Dec 2015 18:54:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16616 invoked from network); 15 Dec 2015 18:54:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 18:54:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 15 Dec 2015 13:54:03 -0500 (EST) Received: (qmail 3511 invoked from network); 15 Dec 2015 18:54:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Dec 2015 18:54:03 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 38B9B1C43BC; Tue, 15 Dec 2015 10:54:00 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix From: Mark Millard In-Reply-To: <56705DEB.2030004@FreeBSD.org> Date: Tue, 15 Dec 2015 10:54:02 -0800 Cc: "Simon J. Gerraty" , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <1F2AC0BD-8963-46BA-9C1B-EB5F48CDA204@dsl-only.net> References: <2426.1449521335@chaos> <56675638.5010904@FreeBSD.org> <56705DEB.2030004@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 18:54:06 -0000 On 2015-Dec-15, at 10:37 AM, Bryan Drewery wrote: >=20 > On 12/8/15 2:14 PM, Bryan Drewery wrote: >> On 12/7/15 1:33 PM, Mark Millard wrote: >>>=20 >>>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty = wrote: >>>>=20 >>>> Mark Millard wrote: >>>>> My guess is that it is picking up the >>>>>=20 >>>>> MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain >>>>=20 >>>> You should use ?=3D if you want this to work. >>>> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is = tweaked >>>> in the environment of a sub-make. >>>>=20 >>>> By using =3D above, you break that. >>>=20 >>> That presumes that MAKEOBJDIRPREFIX has not been assigned a default = value before the SRC_ENV_CONF file has been included the first time. If = MAKEOBJDIRPREFIX had been defined already then the ?=3D would do nothing = and the wrong value would be used. >>>=20 >>> I believe that the following trace shows that such an assignment of = a default value does happen first, making ?=3D not work either. >>>=20 >>>=20 >>>=20 >>> /usr/src/Makefile (head/Makefile 29160) has >>>=20 >>>> MAKEOBJDIRPREFIX?=3D /usr/obj >>>=20 >>> at line 145 (used when it is not using targets/Makefile from the = relevant .if/.else/.endif). >>>=20 >>> Line 105 has .include and there no others before = the above assignment. bsd.compiler.mk in turn includes bsd.opt.mk = (only), which in turns includes bsd.mkopt.mk (only). That in turn = includes nothing else. So these files and only these files are the = involved files before that assignment as far as I can tell. >>>=20 >>> None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not = happened yet when=20 >>>=20 >>>> MAKEOBJDIRPREFIX?=3D /usr/obj >>>=20 >>> is executed. >>>=20 >>> So, if I understand right, MAKEOBJDIRPREFIX is already defined = before the code >>>=20 >>>> SRC_ENV_CONF?=3D /etc/src-env.conf >>>> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_) >>>> .-include "${SRC_ENV_CONF}" >>>> _src_env_conf_included_: .NOTMAIN >>>> .endif >>>=20 >>> is executed and so using ?=3D would not be effective in the included = file. >>>=20 >>> Did I miss something? >>=20 >>=20 >> Yes. sys.mk and src-env.conf are included *before* Makefile. Think of = it >> as being in line 0. >>=20 >> Technically you should be able to use MAKEOBJDIRPREFIX in make.conf = or >> src.conf if you are not using any of the meta mode features (all off = by >> default). >>=20 >=20 > Clarification: We *could* support this but it does not work today. We > can use .OBJDIR to force using a MAKEOBJDIRPREFIX from make.conf but > only if we also force creating the directory as well. Getting this all > right just ends up falling into the new auto.obj.mk territory anyhow. = I > do want to expand that to the default build, which would allow setting > MAKEOBJDIRPREFIX in src-env.conf. So may be the paragraph below from "man src.conf" should not (yet?) = suggest that MAKEOBJDIRPREFIX is valid in a file to be referenced by = SRC_ENV_CONF: > The environment of make(1) for the build can be controlled via the > SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some > examples that may only be set in this file are MAKEOBJDIRPREFIX, > WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are = environment-only > variables. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Dec 15 18:54:54 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAF51A48A9F; Tue, 15 Dec 2015 18:54:53 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BE6971AFE; Tue, 15 Dec 2015 18:54:53 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B24E01686; Tue, 15 Dec 2015 18:54:53 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 74E7B176C8; Tue, 15 Dec 2015 18:54:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Ds6kXu0iQB13; Tue, 15 Dec 2015 18:54:50 +0000 (UTC) Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 79D54176BE To: Mark Millard References: <2426.1449521335@chaos> <56675638.5010904@FreeBSD.org> <56705DEB.2030004@FreeBSD.org> <1F2AC0BD-8963-46BA-9C1B-EB5F48CDA204@dsl-only.net> Cc: "Simon J. Gerraty" , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current From: Bryan Drewery Organization: FreeBSD Message-ID: <567061F8.4040508@FreeBSD.org> Date: Tue, 15 Dec 2015 10:54:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1F2AC0BD-8963-46BA-9C1B-EB5F48CDA204@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 18:54:54 -0000 On 12/15/15 10:54 AM, Mark Millard wrote: > On 2015-Dec-15, at 10:37 AM, Bryan Drewery wrote: >> >> On 12/8/15 2:14 PM, Bryan Drewery wrote: >>> On 12/7/15 1:33 PM, Mark Millard wrote: >>>> >>>>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote: >>>>> >>>>> Mark Millard wrote: >>>>>> My guess is that it is picking up the >>>>>> >>>>>> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain >>>>> >>>>> You should use ?= if you want this to work. >>>>> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked >>>>> in the environment of a sub-make. >>>>> >>>>> By using = above, you break that. >>>> >>>> That presumes that MAKEOBJDIRPREFIX has not been assigned a default value before the SRC_ENV_CONF file has been included the first time. If MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and the wrong value would be used. >>>> >>>> I believe that the following trace shows that such an assignment of a default value does happen first, making ?= not work either. >>>> >>>> >>>> >>>> /usr/src/Makefile (head/Makefile 29160) has >>>> >>>>> MAKEOBJDIRPREFIX?= /usr/obj >>>> >>>> at line 145 (used when it is not using targets/Makefile from the relevant .if/.else/.endif). >>>> >>>> Line 105 has .include and there no others before the above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), which in turns includes bsd.mkopt.mk (only). That in turn includes nothing else. So these files and only these files are the involved files before that assignment as far as I can tell. >>>> >>>> None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not happened yet when >>>> >>>>> MAKEOBJDIRPREFIX?= /usr/obj >>>> >>>> is executed. >>>> >>>> So, if I understand right, MAKEOBJDIRPREFIX is already defined before the code >>>> >>>>> SRC_ENV_CONF?= /etc/src-env.conf >>>>> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_) >>>>> .-include "${SRC_ENV_CONF}" >>>>> _src_env_conf_included_: .NOTMAIN >>>>> .endif >>>> >>>> is executed and so using ?= would not be effective in the included file. >>>> >>>> Did I miss something? >>> >>> >>> Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it >>> as being in line 0. >>> >>> Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or >>> src.conf if you are not using any of the meta mode features (all off by >>> default). >>> >> >> Clarification: We *could* support this but it does not work today. We >> can use .OBJDIR to force using a MAKEOBJDIRPREFIX from make.conf but >> only if we also force creating the directory as well. Getting this all >> right just ends up falling into the new auto.obj.mk territory anyhow. I >> do want to expand that to the default build, which would allow setting >> MAKEOBJDIRPREFIX in src-env.conf. > > > So may be the paragraph below from "man src.conf" should not (yet?) suggest that MAKEOBJDIRPREFIX is valid in a file to be referenced by SRC_ENV_CONF: > >> The environment of make(1) for the build can be controlled via the >> SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some >> examples that may only be set in this file are MAKEOBJDIRPREFIX, >> WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are environment-only >> variables. > > Yes, I fixed it after my mail. -- Regards, Bryan Drewery From owner-freebsd-ppc@freebsd.org Tue Dec 15 22:49:08 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96B9AA48349 for ; Tue, 15 Dec 2015 22:49:08 +0000 (UTC) (envelope-from knowledgeispower80@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1BB1F28 for ; Tue, 15 Dec 2015 22:49:08 +0000 (UTC) (envelope-from knowledgeispower80@gmail.com) Received: by mail-ig0-x22b.google.com with SMTP id xm8so25895021igb.1 for ; Tue, 15 Dec 2015 14:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=V3ObJEfy8/2yG8wpbzMTVi3u0+/g0Hfcg1bExLxXjzk=; b=thk9Q7yZDZv7zRbBJLAiWpsC7J2IdwZxXMjWkXNORDGXnWDc9IVwMYkk5se6u8vGum Xvvmi0kWgJkdPqtPQ+OXxEYdpQi2C1RLD38+YuKDKtiX0A54zTPn910csjBXXFvAfkWJ t0ArhjwxO1sZ07FraKM3VrQv0zgKXaw7hAolujNDQQ/hmgSCqfOyNCbKqKM2VRYlB2NF k2JxaYCaFYoSZyPespGWxiFFwdETRvF9pWYBe7fgfdX3jUPGSdFQDJeMAgrSwMsf7xtb rVwkRjp3eiMH7ct5vs2CNVboBGExRJ2TlkfqwLSSzIUB0eyJEEfGlaCH/FMKIYP8uF8B X13Q== MIME-Version: 1.0 X-Received: by 10.50.12.101 with SMTP id x5mr6528228igb.68.1450219747934; Tue, 15 Dec 2015 14:49:07 -0800 (PST) Received: by 10.36.93.197 with HTTP; Tue, 15 Dec 2015 14:49:07 -0800 (PST) Date: Tue, 15 Dec 2015 17:49:07 -0500 Message-ID: Subject: radeon ppc64 From: Roosevelt Littleton To: freebsd-ppc@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 22:49:08 -0000 I have a radeon gpu. The radeon-ums driver was removed from the tree. What are my options if I want to use X? Thanks From owner-freebsd-ppc@freebsd.org Wed Dec 16 01:55:05 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FA7DA49A66; Wed, 16 Dec 2015 01:55:05 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E2FFC1EB0; Wed, 16 Dec 2015 01:55:04 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id tBG1t1o1070496 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Dec 2015 02:55:02 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id tBG1t01h070495; Wed, 16 Dec 2015 02:55:00 +0100 (CET) (envelope-from marius) Date: Wed, 16 Dec 2015 02:55:00 +0100 From: Marius Strobl To: Andrew Turner Cc: freebsd-sparc64@FreeBSD.org, freebsd-ppc@FreeBSD.org Subject: Re: Testing an Open Firmware interrupt-map patch Message-ID: <20151216015500.GA70379@alchemy.franken.de> References: <20151214134625.79283652@zapp> <20151214234710.GA32903@alchemy.franken.de> <20151215002830.2531673d@zapp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151215002830.2531673d@zapp> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Wed, 16 Dec 2015 02:55:02 +0100 (CET) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 01:55:05 -0000 On Tue, Dec 15, 2015 at 12:28:30AM +0000, Andrew Turner wrote: > On Tue, 15 Dec 2015 00:47:10 +0100 > Marius Strobl wrote: > > > On Mon, Dec 14, 2015 at 01:46:25PM +0000, Andrew Turner wrote: > > > Hello, > > > > > > I'm looking for testers for a patch to update how we parse the > > > interrupt-map property to follow the ePAPR spec. This property is > > > commonly used with PCIe controllers. > > > > > > The current code doesn't take the parent address size property. When > > > this is non-zero we need to also read these values. This is needed > > > on an arm64 board I have as the interrupt parent has memory-mapped > > > children so needs this to be set. > > > > > > I have a patch at [1] to add this, however would like it if this > > > could be tested on other platforms using this code to check it > > > doesn't break these platforms before I commit it. > > > > + "#address-cells", &paddrsz, sizeof(paddrsz)) == > > -1) > > + paddrsz = 0; /* default */ > > > > According to IEEE 1275-1994 (page 110) the default in case of a > > "#address-cells" property is 2 (see also ofw_bus_setup_iinfo()), > > with the latter also being known as the correct default value > > for sparc64 machines. > > However both Linux and NetBSD have similar code, both assume a missing > interrupt-parent #address-size property the correct value is 0. According to ePAPR v1.1, the default in case of missing "#address-cells" properties also is 2 (page 24). However, it also says that the open-pic node/parent interrupt domain has an "#address-cells" value of 0 (page 36). So the above snippet appears more like a workaround for broken device trees as far as ePAPR is concerned, at least the comment "default" is misleading in that regard. > > In any case, this will have quite an impact on the offset > > calculation on sparc64 machines for e. g. EBusses beneath PCI > > busses (which use 3 address cells there) and, thus, most likely > > will cause havoc. Maybe the parent unit address should be only > > taken into account on platforms using interrupt parents? > > It would seem there is a difference between the encoding on Sparc64 and > ePAPR. Using the the parent #address-size may lead to incorrect parsing > on Sparc64, as such I will disable it there. > Yes, as the name suggests, ePAPR is a specification for the Power Architecture. Originally, ofw_bus_search_intrmap() also was sparc64 MD code until nwhitehorn@ in r186128 brought it over to the truly MI sys/dev/ofw/ofw_bus_subr.c I had started. Actually, as for the parent unit address in the interrupt map table ePAPR v1.1 specifically refers to the interrupt parent (page 34). So in order to avoid an #if !defined(__sparc64__) in MI code it seems best to do what I suggested above and to apply paddrsz only on the platforms that actually use interrupt parents. Alternatively, please at least invert it to an #if defined(OFW_EPAPR) and define OFW_EPAPR in sys//include/ofw_machdep.h as applicable. Marius From owner-freebsd-ppc@freebsd.org Wed Dec 16 14:01:03 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD9EAA439FB for ; Wed, 16 Dec 2015 14:01:03 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) Received: from mailer238.gate85.rs.smtp.com (mailer238.gate85.rs.smtp.com [74.91.85.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 700831C67 for ; Wed, 16 Dec 2015 14:01:02 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) X-MSFBL: eyJiIjoiNzRfOTFfODVfMjM4IiwiZyI6IlNuc3RlbGVjb21fZGVkaWNhdGVkX3Bv b2wiLCJyIjoiZnJlZWJzZC1wcGNAZnJlZWJzZC5vcmcifQ== Received: from [192.168.80.11] ([192.168.80.11:60724] helo=rs-ord-mta01-1.smtp.com) by rs-ord-mta04-3.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTP id C6/09-03821-58631765; Wed, 16 Dec 2015 10:01:41 +0000 X-MSFBL: eyJiIjoiU25zdGVsZWNvbV9kZWRpY2F0ZWRfcG9vbCIsImciOiJTbnN0ZWxlY29t X2RlZGljYXRlZF9wb29sIiwiciI6ImZyZWVic2QtcHBjQGZyZWVic2Qub3JnIn0= DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1450260101; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=eaDkPWH2EipYAgkQ/cTGNAEBgNVwjyq+94ZOrg0MofY=; b=vro7Et3sBSrN3uagVRaiHKy254BTsq6aYd4OBjikelBbfry/zBkyf4Jv/z7CIWGa Ea06+czlw1S3+sZipGv2MdZWf02InwJiSL2vtr7LsX6ajA1/TQ9I6Oe2NEWGhKLZ DLDXLli1IYbARAdtDfSjyA54ikc4lC9XZLPSbu6vqFg=; Received: from [154.20.125.37] ([154.20.125.37:52522] helo=d154-20-125-37.bchsia.telus.net) by rs-ord-mta01-1.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id 44/EE-24698-48631765; Wed, 16 Dec 2015 10:01:41 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snscommunication.com To: freebsd-ppc@freebsd.org Subject: The SDN, NFV & Network Virtualization Ecosystem: 2015 - 2030 - Opportunities, Challenges, Strategies & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Wed, 16 Dec 2015 02:01:39 -0800 Message-ID: <55124199079682390428332@Ankur> X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com X-SMTPCOM-Tracking-Number: 60c137f9-87f5-4e6b-a4fb-c3424e8ecd1f X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 14:01:03 -0000 The SDN, NFV & Network Virtualization Ecosystem: 2015 =96 2030 =96 Opportun= ities, Challenges, Strategies & Forecasts Hello=20 I wanted to bring to your attention the latest SNS Research report in which= you might be interested, " The SDN, NFV & Network Virtualization Ecosystem= : 2015 =96 2030 =96 Opportunities, Challenges, Strategies & Forecasts."=20 I believe this report will be highly applicable for you and your team. If y= ou would like to see the report sample or have any questions, please let me= know. =20 Report Information: Release Date: December 2015 Number of Pages: 429 Number of Tables and Figures: 89 Report Overview: While the advantages of SDN (Software Defined Networking) and network virtu= alization are well known in the enterprise IT and data center world, both t= echnologies also bring a host of benefits to the telecommunications service= provider community. Not only can these technologies help address the explo= sive capacity demand of mobile traffic, but they can also reduce the CapEx = and OpEx burden faced by service providers to handle this demand by diminis= hing reliance on expensive proprietary hardware platforms. The recognition = of these benefits has led to the emergence of the NFV (Network Functions Vi= rtualization) concept that seeks to virtualize and effectively consolidate = many service provider network elements onto multi-tenant industry-standard = servers, switches and storage. Mobile operators and internet service providers have already begun making S= DN and NFV investments in a number of functional areas including but not li= mited to EPC/mobile core, IMS, policy control, CPE (Customer Premises Equip= ment), CDN (Content Delivery Network) and transport networks. SNS Research = estimates that service provider SDN and NFV investments will grow at a CAGR= of 54% between 2015 and 2020. As service providers seek to reduce costs an= d virtualize their networks, these investments will eventually account for = over $20 Billion in revenue by the end of 2020. The =93SDN, NFV & Network Virtualization Ecosystem: 2015 =96 2030 =96 Oppor= tunities, Challenges, Strategies & Forecasts=94 report presents an in-depth= assessment of the SDN, NFV and network virtualization ecosystem including = enabling technologies, key trends, market drivers, challenges, use cases, d= eployment case studies, regulatory landscape, standardization, opportunitie= s, future roadmap, value chain, ecosystem player profiles and strategies. T= he report also presents market size forecasts from 2015 till 2030. The fore= casts are segmented for 10 submarkets, 2 user base categories, 9 use cases,= 6 regions and 34 countries. The report comes with an associated Excel datasheet suite covering quantita= tive data from all numeric forecasts presented in the report. =20 Key Findings: The report has the following key findings: SNS Research estimates that service provider SDN and NFV investments will g= row at a CAGR of 54% between 2015 and 2020, eventually accounting for over = $20 Billion in revenue by the end of 2020. At present, virtualized EPC/mobile core, IMS and policy control platforms r= epresent over 70% of all VNF (Virtual Network Function) software investment= s. Although the use of SDN is widespread in the enterprise and data center dom= ain, service providers are only beginning to adopt the technology to progra= mmatically manage their networks. Investments on orchestration platforms will account for nearly $2 Billion i= n revenue by the end of 2020, representing nearly 10% of all service provid= er SDN and NFV spending. The growing adoption of SDN and NFV has created a natural opportunity for s= ilicon and server OEMs to combine their server platforms with a networking = business stream. Topics Covered: The report covers the following topics: SDN, NFV and network virtualization ecosystem Market drivers and barriers Enabling technologies, protocols, architecture and key trends Use cases, applications, PoC (Proof of Concept) and deployment case studies CapEx saving potential of SDN and NFV Orchestration and management platforms Regulatory landscape and standardization Industry roadmap and value chain Profiles and strategies of over 240 leading ecosystem players Strategic recommendations for ecosystem players Market analysis and forecasts from 2015 till 2030 Forecast Segmentation: Market forecasts are provided for each of the following submarkets, user ba= se and use case categories:=20 Submarkets SDN Hardware & Software NFV Hardware & Software Other Network Virtualization Software User Base Categories Service Providers Enterprises & Data Centers NFV Submarkets Hardware Appliances Orchestration & Management Software VNF Software Service Provider SDN Submarkets SDN-Enabled Hardware Appliances Orchestration & Management Software SDN Controller Software Network Applications Software Enterprise & Data Center SDN Submarkets SDN-Enabled Hardware Appliances SDN-Enabled Virtual Switches SDN Controller Software Service Provider Use Case Categories CDN CPE Data Center EPC/Mobile Core Fixed Access Networks IMS & VoLTE Policy, OSS & BSS RAN (Radio Access Network) Transport & Backhaul Regional Markets Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe Country Markets Argentina, Australia, Brazil, Canada, China, Czech Republic, Denmark, Finla= nd, France, Germany, India, Indonesia, Israel, Italy, Japan, Malaysia, Mex= ico, Norway, Pakistan, Philippines, Poland, Qatar, Russia, Saudi Arabia, Si= ngapore, South Africa, South Korea, Spain, Sweden, Taiwan, Thailand, UAE, U= K and USA Additional forecasts are provided for: SDN and NFV Induced Service Provider CapEx Savings by Region Key Questions Answered: The report provides answers to the following key questions: How big is the SDN, NFV and network virtualization opportunity=3F What trends, challenges and barriers are influencing its growth=3F How is the ecosystem evolving by segment and region=3F What will the market size be in 2020 and at what rate will it grow=3F Which regions, submarkets and countries will see the highest percentage of = growth=3F How are service provider led initiatives driving SDN and NFV investments=3F How does regulation impact the adoption of SDN and NFV centric networks=3F How can NFV make the VoLTE (Voice over LTE) business case work=3F How can software defined DPI (Deep Packet Inspection) complement SDN functi= onality=3F What level of CapEx savings can SDN and NFV facilitate for service provider= s=3F Do SDN and NFV pose a threat to traditional network infrastructure vendors=3F Who are the key market players and what are their strategies=3F Is there a ring leader in the SDN and NFV ecosystem=3F What strategies should enabling technology providers, network infrastructur= e vendors, mobile operators and other ecosystem players adopt to remain com= petitive=3F Report Pricing: Single User License: USD 2,500 Company Wide License: USD 3,500 Ordering Process: Please contact Andy Silva on andy.silva@snscommunication.com Provide the following information: 1. Report Title - 2. Report License - (Single User/Company Wide) 3. Name - 4. Email - 5. Job Title - 6. Company - 7. Invoice Address - Please contact me if you have any questions, or wish to purchase a copy. Ta= ble of contents and List of figures mentioned below for your better inside. I look forward to hearing from you. Kind Regards Andy Silva Marketing Executive Signals and Systems Telecom Reef Tower Jumeirah Lake Towers Sheikh Zayed Road Dubai, UAE =20 ___________________________________________________________________________= __________________________________________________________________________ =20 Table of Content =20 1.1 Executive Summary 1.2 Topics Covered 1.3 Forecast Segmentation 1.4 Key Questions Answered 1.5 Key Findings 1.6 Methodology 1.7 Target Audience 1.8 Companies & Organizations Mentioned =20 2 Chapter 2: An Overview of SDN, NFV & Network Virtualization 2.1 What is Network Virtualization=3F 2.2 What is SDN (Software Defined Networking)=3F 2.3 SDN Protocols 2.3.1 OpenFlow 2.3.2 BGP-TE (Border Gateway Protocol - Traffic Engineering) 2.3.3 PCEP (Path Computation Element Protocol) 2.3.4 I2RS (Interface to the Routing System) 2.3.5 VxLAN (Virtual Extensible LAN) 2.3.6 ALTO (Application Layer Traffic Optimization) 2.3.7 IETF Software Driven Networks 2.4 SDN Implementation Approaches 2.4.1 Network Virtualization Approach 2.4.2 Evolutionary Approach 2.4.3 The =93Central Control=94 Approach 2.5 What is NFV (Network Functions Virtualization)=3F 2.6 NFV Enabling Technologies 2.6.1 Cloud Computing and Network Virtualization 2.6.2 Open Management and Control Protocols 2.6.3 Industry Standard High-Volume Servers 2.7 NFV Implementation Architecture 2.7.1 NFVI (NFV Infrastructure) 2.7.1.1 Hardware Resources 2.7.1.2 Virtualized Resources 2.7.2 VNFs (Virtualized Network Functions) 2.7.3 NFV-MANO (NFV-Management and Orchestration) 2.7.3.1 VIM (Virtualized Infrastructure Manager) 2.7.3.2 Orchestrator 2.7.3.3 VNF Manager 2.8 How SDN and NFV Differ from Each Other=3F 2.8.1 Similarities and Differences 2.8.2 Can Both Technologies Complement Each Other=3F 2.8.3 How Are Vendors Positioning their Solutions=3F 2.9 Market Drivers 2.9.1 Leveraging Generic Low-cost Hardware 2.9.2 Multi-tenancy on Same Hardware 2.9.3 Reduced Power Consumption 2.9.4 Faster TTM (Time to Market) 2.9.5 Improved Operational Efficiency & Performance 2.9.6 Centralized Provisioning and Network Control 2.9.7 Ability to Launch New Services & Virtual Networks Quickly 2.9.8 Dynamic Scaling of Services 2.9.9 Opening the Door to Multi-vendor Interoperability 2.9.10 CapEx and OpEx Reduction 2.9.11 Fast Troubleshooting and Improved Diagnostics 2.9.12 Vendor Support 2.10 Market Barriers 2.10.1 Lack of Standardization & Technology Maturity 2.10.2 Uncertain Cost-Benefits Tradeoffs 2.10.3 NFV May Slow/Delay Traffic 2.10.4 Will Multi-vendor Interoperability Really Work=3F 2.10.5 Co-Existence with Legacy Networks: Integration Challenges =20 3 Chapter 3: SDN & NFV Use Case Scenarios 3.1 Enterprise, Data Center & Generic Use Cases 3.1.1 Network Virtualization 3.1.2 Scalable Data Centers 3.1.3 Tap Aggregation 3.1.4 Dynamic WAN Re-Routing 3.1.5 Network Exchange: Interconnecting Physical Networks 3.1.6 Improved Traffic Engineering 3.1.7 Converged Storage 3.2 Service Provider Centric Use Cases 3.2.1 RAN Virtualization 3.2.2 C-RAN (Cloud RAN) 3.2.3 Wireline Fixed Access Network Virtualization 3.2.4 CPE & Home Network Environment Virtualization 3.2.5 Mobile Backhaul Virtualization 3.2.6 EPC/Mobile Core Virtualization 3.2.7 IMS & VoLTE Virtualization 3.2.8 DPI Virtualization 3.2.9 Policy Functions Virtualization 3.2.10 Virtual Routers 3.2.11 Virtualization & Control of Security Functions 3.2.12 Virtualization of CDNs 3.2.13 Service Chaining 3.2.14 Bandwidth on Demand 3.2.15 Packet-Optical Integration 3.2.16 SDN/NFV Iaas (Infrastructure as a Service) 3.2.17 VNFaas (Virtual Network Function as a Service) 3.2.18 VNPaaS (Virtual Network Platform as a Service) =20 4 Chapter 4: SDN & NFV Deployment Case Studies 4.1 Service Provider Deployment Case Studies 4.1.1 AT&T 4.1.2 BT Group 4.1.3 China Mobile 4.1.4 DT (Deutsche Telekom) 4.1.5 KDDI Corporation 4.1.6 KT Corporation 4.1.7 LG Uplus 4.1.8 Mobily Saudi Arabia 4.1.9 NAKA Mobile 4.1.10 NTT Communications 4.1.11 NTT DoCoMo 4.1.12 PT (Portugal Telecom) /Oi 4.1.13 SingTel 4.1.14 SK Telecom 4.1.15 SoftBank 4.1.16 Telekom Austria Group 4.1.17 Telstra 4.1.18 Telef=F3nica 4.1.19 Verizon 4.1.20 Vodafone Group 4.2 Enterprise & Data Center Deployment Case Studies 4.2.1 Equinix 4.2.2 Fidelity Investments 4.2.3 Google 4.2.4 Kanazawa University Hospital 4.2.5 Nippon Express =20 5 Chapter 5: Industry Roadmap and Value Chain 5.1 The SDN, NFV & Network Virtualization Value Chain 5.1.1 Silicon & Server OEMs 5.1.2 Pure-play SDN/NFV Specialists 5.1.3 Network Infrastructure Vendors 5.1.4 IT Industry Giants 5.1.5 Mobile Infrastructure Vendors 5.1.6 Policy, OSS, BSS & Other Software Vendors 5.1.7 Enterprises 5.1.8 Service Providers 5.1.9 Data Center Operators 5.2 The SDN, NFV & Network Virtualization Industry Roadmap: 2015 - 2030 5.2.1 2015 =96 2020: Moving Towards Network Wide Orchestration 5.2.2 2020 =96 2025: Large Scale Proliferation in Service Provider Networks 5.2.3 2025 =96 2030: Continued Investments with 5G Rollouts =20 6 Chapter 6: Standardization Bodies & Alliances 6.1 3GPP (3rd Generation Partnership Project) 6.2 ETSI (European Telecommunications Standards Institute) 6.3 Cloud NFV 6.4 IETF (Internet Engineering Task Force) 6.5 IRTF (Internet Research Task Force) 6.6 ITU (International Telecommunications Union) 6.7 MEF (Metro Ethernet Forum) 6.8 ONF (Open Networking Foundation) 6.9 OpenDaylight 6.10 OpenStack Foundation 6.11 ONRC (Open Networking Research Center) and ON.Lab (Open Networking Lab) 6.12 OPNFV (Open Platform for NFV) 6.13 OVA (Open Virtualization Alliance) 6.14 OMG (Object Management Group) 6.15 TM Forum 6.16 Vendor Led Initiatives & Ecosystem Programs 6.16.1 Alcatel-Lucent CloudBand Ecosystem Program 6.16.2 Cyan Blue Orbit Ecosystem 6.16.3 HP OpenNFV Application Partner Program 6.16.4 HP SDN Ecosystem Alliance 6.16.5 NEC SDN Partner Space 6.16.6 Intel Network Builders Program 6.16.7 Titanium Cloud Partner Program 6.16.8 Juniper Technology Partner Program 6.16.9 Red Hat NFV Ecosystem 6.16.10 Amdocs Network Cloud Ecosystem =20 7 Chapter 7: Company Profiles 7.1 6WIND 7.2 A10 Networks 7.3 Accedian Networks 7.4 Accton Technology Corporation 7.5 Active Broadband Networks 7.6 Actus Networks 7.7 ADARA Networks 7.8 Adax 7.9 ADLINK Technology 7.10 ADTRAN 7.11 ADVA Optical Networking 7.12 Affirmed Networks 7.13 Agema Systems 7.14 Akamai Technologies 7.15 ALAXALA Networks Corporation 7.16 Albis Technologies 7.17 Alcatel-Lucent 7.18 Allied Telesis 7.19 Allot Communications 7.20 Alpha Networks 7.21 ALTEN Calsoft Labs 7.22 Altiostar Networks 7.23 Alvarion Technologies 7.24 AMD (Advanced Micro Devices) 7.25 Amdocs 7.26 ANEVIA 7.27 Argela 7.28 Aricent 7.29 Arista Networks 7.30 Arkoon Netasq 7.31 ARM Holdings 7.32 ARRIS Group 7.33 Artesyn Embedded Technologies 7.34 ASOCS 7.35 AudioCodes 7.36 Avago Technologies 7.37 Avaya 7.38 Barracuda Networks 7.39 Big Switch Networks 7.40 BlueCoat 7.41 Brain4Net 7.42 Broadpeak 7.43 BroadSoft 7.44 Brocade 7.45 BTI Systems 7.46 Canoga Perkins 7.47 Canonical 7.48 Catbird Networks 7.49 Cavium 7.50 Cedexis 7.51 Cellwize 7.52 Centec Networks 7.53 Ceragon Networks 7.54 Certes Networks 7.55 Check Point Software Technologies 7.56 Ciena 7.57 Cisco Systems 7.58 Citrix Systems 7.59 Clavister 7.60 ClearPath Networks 7.61 CloudWeaver 7.62 Cobham Wireless 7.63 Cohesive Networks 7.64 Colt Technology Services Group 7.65 Comodo Security Solutions 7.66 Compass-EOS 7.67 Comptel 7.68 Concurrent 7.69 Coriant 7.70 Corsa Technology 7.71 CSC (Computer Sciences Corporation) 7.72 Cumulus Networks 7.73 Cyan 7.74 Dell 7.75 Dialogic 7.76 Dorado Software 7.77 ECI Telecom 7.78 Edgeware 7.79 Ekinops 7.80 Elemental Technologies 7.81 EMC Corporation 7.82 EnterpriseWeb 7.83 Ericsson 7.84 EXFO 7.85 Extreme Networks 7.86 EZchip Semiconductor 7.87 F5 Networks 7.88 FibroLAN 7.89 Flash Networks 7.90 Flextronics International 7.91 Fortinet 7.92 FRAFOS 7.93 Fujitsu 7.94 GENBAND 7.95 Gencore Systems 7.96 Gigamon 7.97 GigaSpaces Technologies 7.98 Guavus 7.99 H3C Technologies 7.100 Harmonic 7.101 Hitachi 7.102 HP (Hewlett-Packard) 7.103 Huawei 7.104 HyTrust 7.105 IBM 7.106 Illumio 7.107 Imagine Communications Corporation 7.108 Infinera 7.109 Infoblox 7.110 Inocybe Technologies 7.111 Intel Corporation 7.112 Interface Masters Technologies 7.113 Intracom Telecom 7.114 Intune Networks 7.115 IP Infusion 7.116 IPgallery 7.117 iPhotonix 7.118 IPITEK 7.119 Italtel 7.120 iwNetworks 7.121 Ixia 7.122 Juniper 7.123 KEMP Technologies 7.124 Lemko Corporation 7.125 Lenovo 7.126 Lumeta Corporation 7.127 Luxoft Holding 7.128 Maipu Communication Technology 7.129 Marvell Technology Group 7.130 MatrixStream Technologies 7.131 MediaTek 7.132 Mellanox Technologies 7.133 Metaswitch Networks 7.134 Microsoft 7.135 Midokura 7.136 Mirantis 7.137 Mitel Networks Corporation 7.138 Mojatatu Networks 7.139 MRV Communications 7.14 Nakina Systems 7.141 Napatech 7.142 NCLC (NCL Communication) 7.143 NEC Corporation 7.144 NetCracker Technology 7.145 NETGEAR 7.146 Netronome 7.147 Netrounds 7.148 NetScout Systems 7.149 NetYCE 7.15 NFVWare 7.151 Nokia Networks 7.152 Nominum 7.153 NoviFlow 7.154 NTT Communications 7.155 NXP Semiconductors 7.156 Omnitron Systems 7.157 Openet 7.158 Openwave Mobility 7.159 Opera Software 7.16 Optelian 7.161 Oracle Corporation 7.162 Orchestral networks 7.163 Overture Networks 7.164 OX (Open-Xchange) 7.165 Ozono Security 7.166 Packet Ship Technologies 7.167 Padtec 7.168 Parallel Wireless 7.169 Palo Alto Networks 7.17 Panda Security 7.171 Pantheon Technologies 7.172 PeerApp 7.173 Penguin 7.174 Pertino 7.175 Pica8 7.176 Plexxi 7.177 PLUMgrid 7.178 Pluribus Networks 7.179 Polatis 7.18 Procera Networks 7.181 Qosmos 7.182 Qualcomm 7.183 Quanta Computer 7.184 Quortus 7.185 Rackspace 7.186 RAD Data Communications 7.187 Radisys Corporation 7.188 Radware 7.189 Rapid7 7.19 Realtek Semiconductor Corporation 7.191 Red Hat 7.192 Redknee 7.193 RightScale 7.194 Riverbed Technology 7.195 Ruckus Wireless 7.196 Saisei 7.197 Samsung Electronics 7.198 Sandvine 7.199 Sansay 7.2 Sencore 7.201 SevOne 7.202 Silver Peak Systems 7.203 Sonus Networks 7.204 Sophos 7.205 Sorrento Networks 7.206 SpiderCloud Wireless 7.207 Spirent Communications 7.208 StackIQ 7.209 SunTec Business Solutions 7.21 Supermicro (Super Micro Computer) 7.211 Svarog Technology Group 7.212 Symantec Corporation 7.213 SysMaster 7.214 Tango Telecom 7.215 TE Connectivity 7.216 Tejas Networks 7.217 Telchemy 7.218 Telco Systems 7.219 Telcoware 7.22 Telum 7.221 Thomson Video Networks 7.222 TI (Texas Instruments) 7.223 Tieto 7.224 TitanHQ 7.225 Transmode 7.226 Trend Micro 7.227 UBIqube 7.228 Ultra Electronics AEP 7.229 UTStarcom 7.23 vArmour 7.231 Versa Networks 7.232 Veryx Technologies 7.233 Viavi Solutions 7.234 VMware 7.235 WatchGuard Technologies 7.236 Wavenet 7.237 WebNMS 7.238 Wedge Networks 7.239 Wipro 7.24 Wowza Media Systems 7.241 Xilinx 7.242 XOR Media 7.243 Xtera Communications 7.244 Xura 7.245 Zhone Technologies 7.246 ZTE =20 8 Chapter 8: Market Analysis & Forecasts 8.1 Global Outlook of SDN, NFV & Network Virtualization Revenue: 2015 - 2030 8.2 User Base Segmentation 8.2.1 Enterprises & Data Centers 8.2.2 Service Providers 8.3 Submarket Segmentation 8.3.1 SDN Hardware & Software 8.3.2 NFV Hardware & Software 8.3.3 Other Network Virtualization Software 8.3.4 Service Provider Submarket Segmentation 8.4 SDN Submarket Revenue: 2015 =96 2030 8.4.1 User Base Segmentation 8.4.2 Service Provider SDN 8.4.3 Enterprise & Data Center SDN 8.5 NFV Submarket Revenue: 2015 =96 2030 8.5.1 Hardware Appliances 8.5.2 Orchestration & Management Software 8.5.3 VNF Software 8.6 Service Provider SDN Submarket Revenue: 2015 =96 2030 8.6.1 SDN-Enabled Hardware Appliances 8.6.2 Orchestration & Management Software 8.6.3 SDN Controller Software 8.6.4 Network Applications Software 8.7 Enterprise & Data Center SDN Submarket Revenue: 2015 =96 2030 8.7.1 SDN-Enabled Hardware Appliances 8.7.2 SDN-Enabled Virtual Switches 8.7.3 SDN Controller Software 8.8 Functional Area Segmentation for Service Provider Deployments 8.8.1 CDN 8.8.2 CPE 8.8.3 Data Center 8.8.4 EPC/Mobile Core 8.8.5 Fixed Access Networks 8.8.6 IMS & VoLTE 8.8.7 Policy, OSS & BSS 8.8.8 RAN 8.8.9 Transport & Backhaul 8.9 Regional Outlook 8.1 Asia Pacific SDN, NFV & Network Virtualization Revenue: 2015 - 2030 8.10.1 Australia 8.10.2 China 8.10.3 India 8.10.4 Japan 8.10.5 South Korea 8.10.6 Pakistan 8.10.7 Thailand 8.10.8 Indonesia 8.10.9 Malaysia 8.10.10 Taiwan 8.10.11 Philippines 8.10.12 Singapore 8.10.13 Rest of Asia Pacific 8.11 Eastern Europe SDN, NFV & Network Virtualization Revenue: 2015 - 2030 8.11.1 Czech Republic 8.11.2 Poland 8.11.3 Russia 8.11.4 Rest of Eastern Europe 8.12 Latin & Central America SDN, NFV & Network Virtualization Revenue: 201= 5 - 2030 8.12.1 Argentina 8.12.2 Brazil 8.12.3 Mexico 8.12.4 Rest of Latin & Central America 8.13 Middle East & Africa SDN, NFV & Network Virtualization Revenue: 2015 -= 2030 8.13.1 South Africa 8.13.2 UAE 8.13.3 Qatar 8.13.4 Saudi Arabia 8.13.5 Israel 8.13.6 Rest of the Middle East & Africa 8.14 North America SDN, NFV & Network Virtualization Revenue: 2015 - 2030 8.14.1 USA 8.14.2 Canada 8.15 Western Europe SDN, NFV & Network Virtualization Revenue: 2015 - 2030 8.15.1 Denmark 8.15.2 Finland 8.15.3 France 8.15.4 Germany 8.15.5 Italy 8.15.6 Spain 8.15.7 Sweden 8.15.8 Norway 8.15.9 UK 8.15.10 Rest of Western Europe =20 9 Chapter 9: Conclusion & Strategic Recommendations 9.1 Will SDN & NFV Disrupt the Network Infrastructure Value Chain=3F 9.2 Is There a Ring Leader in the SDN & NFV Ecosystem=3F 9.3 SDN & NFV: Building the Mobile Cloud 9.4 Buyers Will Maintain Focus on Business Agility & CapEx Reduction 9.5 Avoiding the Proprietary Trap 9.6 Will Service Providers Continue to Utilize Proprietary Hardware Platfor= ms=3F 9.7 Making the VoLTE Business Case Work 9.8 How Much CapEx Can Service Providers Save with SDN & NFV Investments=3F 9.9 Prospects of SDN & NFV Orchestration 9.9.1 Different Vendors, Different Approaches 9.9.2 Future Prospects of Harmonization 9.1 Strategic Recommendations 9.10.1 Recommendations for Silicon & Server OEMs 9.10.2 Recommendations for Network & Mobile Infrastructure Vendors & IT Gia= nts 9.10.3 Recommendations for Pure-play SDN/NFV Specialists 9.10.4 Recommendations for Enterprises and Data Center Operators 9.10.5 Recommendations for Service Providers List of Figures: Figure 1: The NFV Concept Figure 2: A Comparison of SDN and NFV Figure 3: C-RAN Architecture Figure 4: Virtualized and Non-Virtualized Mobile Core Networks Figure 5: The SDN, NFV & Network Virtualization Value Chain Figure 6: The SDN, NFV & Network Virtualization Industry Roadmap: 2015 - 20= 30 Figure 7: Global SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ = Million) Figure 8: Global SDN, NFV & Network Virtualization Revenue by User Base: 20= 15 - 2030 ($ Million) Figure 9: Global Enterprise & Data Center SDN & Network Virtualization Reve= nue: 2015 - 2030 ($ Million) Figure 10: Global Service Provider SDN & NFV Revenue by User Base: 2015 - 2= 030 ($ Million) Figure 11: Global SDN, NFV & Network Virtualization Revenue by Submarket: 2= 015 - 2030 ($ Million) Figure 12: Global SDN Hardware & Software Revenue: 2015 - 2030 ($ Million) Figure 13: Global NFV Hardware & Software Revenue: 2015 - 2030 ($ Million) Figure 14: Global Other Network Virtualization Software Revenue: 2015 - 203= 0 ($ Million) Figure 15: Global Service Provider SDN & NFV Revenue by Submarket: 2015 - 2= 030 ($ Million) Figure 16: Global SDN Revenue by User Base: 2015 - 2030 ($ Million) Figure 17: Global Service Provider SDN Hardware & Software Revenue: 2015 - = 2030 ($ Million) Figure 18: Global Enterprise & Data Center SDN Revenue: 2015 - 2030 ($ Mill= ion) Figure 19: Global NFV Revenue by Submarket: 2015 - 2030 ($ Million) Figure 20: Global NFV Hardware Appliance Revenue: 2015 - 2030 ($ Million) Figure 21: Global NFV Orchestration & Management Software Revenue: 2015 - 2= 030 ($ Million) Figure 22: Global NFV VNF Software Revenue: 2015 - 2030 ($ Million) Figure 23: Global Service Provider SDN Revenue by Submarket: 2015 - 2030 ($= Million) Figure 24: Global Service Provider SDN-Enabled Hardware Appliance Revenue: = 2015 - 2030 ($ Million) Figure 25: Global Service Provider SDN Orchestration & Management Revenue: = 2015 - 2030 ($ Million) Figure 26: Global Service Provider SDN Controller Software Revenue: 2015 - = 2030 ($ Million) Figure 27: Global Service Provider SDN Network Applications Software Revenu= e: 2015 - 2030 ($ Million) Figure 28: Global Enterprise & Data Center SDN Revenue by Submarket: 2015 -= 2030 ($ Million) Figure 29: Global Enterprise & Data Center SDN-Enabled Hardware Appliance R= evenue: 2015 - 2030 ($ Million) Figure 30: Global Enterprise & Data Center SDN-Enabled Virtual Switch Reven= ue: 2015 - 2030 ($ Million) Figure 31: Global Enterprise & Data Center SDN Controller Software Revenue:= 2015 - 2030 ($ Million) Figure 32: Global Service Provider SDN & NFV Revenue by Functional Area: 20= 15 - 2030 ($ Million) Figure 33: Global SDN & NFV Revenue in Service Provider CDNs: 2015 - 2030 (= $ Million) Figure 34: Global SDN & NFV Revenue in Service Provider CPE Deployments: 20= 15 - 2030 ($ Million) Figure 35: Global SDN & NFV Revenue in Service Provider Data Centers: 2015 = - 2030 ($ Million) Figure 36: Global SDN & NFV Revenue in Service Provider EPC/Mobile Core Net= works: 2015 - 2030 ($ Million) Figure 37: Global SDN & NFV Revenue in Service Provider Fixed Access Networ= ks: 2015 - 2030 ($ Million) Figure 38: Global SDN & NFV Revenue in Service Provider IMS & VoLTE Network= s: 2015 - 2030 ($ Million) Figure 39: Global SDN & NFV Revenue in Service Provider Policy, OSS & BSS S= ystems: 2015 - 2030 ($ Million) Figure 40: Global SDN & NFV Revenue in Service Provider RANs: 2015 - 2030 (= $ Million) Figure 41: Global SDN & NFV Revenue in Service Provider Transport & Backhau= l Networks: 2015 - 2030 ($ Million) Figure 42: SDN, NFV & Network Virtualization Revenue by Region: 2015 - 2030= ($ Million) Figure 43: Asia Pacific SDN, NFV & Network Virtualization Revenue: 2015 - 2= 030 ($ Million) Figure 44: Australia SDN, NFV & Network Virtualization Revenue: 2015 - 2030= ($ Million) Figure 45: China SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ = Million) Figure 46: India SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ = Million) Figure 47: Japan SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ = Million) Figure 48: South Korea SDN, NFV & Network Virtualization Revenue: 2015 - 20= 30 ($ Million) Figure 49: Pakistan SDN, NFV & Network Virtualization Revenue: 2015 - 2030 = ($ Million) Figure 50: Thailand SDN, NFV & Network Virtualization Revenue: 2015 - 2030 = ($ Million) Figure 51: Indonesia SDN, NFV & Network Virtualization Revenue: 2015 - 2030= ($ Million) Figure 52: Malaysia SDN, NFV & Network Virtualization Revenue: 2015 - 2030 = ($ Million) Figure 53: Taiwan SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 54: Philippines SDN, NFV & Network Virtualization Revenue: 2015 - 20= 30 ($ Million) Figure 55: Singapore SDN, NFV & Network Virtualization Revenue: 2015 - 2030= ($ Million) Figure 56: SDN, NFV & Network Virtualization Revenue in the Rest of Asia Pa= cific: 2015 - 2030 ($ Million) Figure 57: Eastern Europe SDN, NFV & Network Virtualization Revenue: 2015 -= 2030 ($ Million) Figure 58: Czech Republic SDN, NFV & Network Virtualization Revenue: 2015 -= 2030 ($ Million) Figure 59: Poland SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 60: Russia SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 61: SDN, NFV & Network Virtualization Revenue in the Rest of Eastern= Europe: 2015 - 2030 ($ Million) Figure 62: Latin & Central America SDN, NFV & Network Virtualization Revenu= e: 2015 - 2030 ($ Million) Figure 63: Argentina SDN, NFV & Network Virtualization Revenue: 2015 - 2030= ($ Million) Figure 64: Brazil SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 65: Mexico SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 66: SDN, NFV & Network Virtualization Revenue in the Rest of Latin &= Central America: 2015 - 2030 ($ Million) Figure 67: Middle East & Africa SDN, NFV & Network Virtualization Revenue: = 2015 - 2030 ($ Million) Figure 68: South Africa SDN, NFV & Network Virtualization Revenue: 2015 - 2= 030 ($ Million) Figure 69: UAE SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ Mi= llion) Figure 70: Qatar SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ = Million) Figure 71: Saudi Arabia SDN, NFV & Network Virtualization Revenue: 2015 - 2= 030 ($ Million) Figure 72: Israel SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 73: SDN, NFV & Network Virtualization Revenue in the Rest of the Mid= dle East & Africa: 2015 - 2030 ($ Million) Figure 74: North America SDN, NFV & Network Virtualization Revenue: 2015 - = 2030 ($ Million) Figure 75: USA SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ Mi= llion) Figure 76: Canada SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 77: Western Europe SDN, NFV & Network Virtualization Revenue: 2015 -= 2030 ($ Million) Figure 78: Denmark SDN, NFV & Network Virtualization Revenue: 2015 - 2030 (= $ Million) Figure 79: Finland SDN, NFV & Network Virtualization Revenue: 2015 - 2030 (= $ Million) Figure 80: France SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 81: Germany SDN, NFV & Network Virtualization Revenue: 2015 - 2030 (= $ Million) Figure 82: Italy SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ = Million) Figure 83: Spain SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ = Million) Figure 84: Sweden SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 85: Norway SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($= Million) Figure 86: UK SDN, NFV & Network Virtualization Revenue: 2015 - 2030 ($ Mil= lion) Figure 87: SDN, NFV & Network Virtualization Revenue in the Rest of Western= Europe: 2015 - 2030 ($ Million) Figure 88: SDN & NFV Induced Service Provider CapEx Saving Potential by Reg= ion: 2015 - 2030 ($ Million) Figure 89: Management & Orchestration Software Revenue by Submarket: 2015 -= 2030 ($ Million) Thank you once again and looking forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snscommunication.com Reef Tower Jumeirah Lake Towers Sheikh Zayed Road Dubai, UAE =20 =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com From owner-freebsd-ppc@freebsd.org Wed Dec 16 14:53:46 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51ABBA48DA4 for ; Wed, 16 Dec 2015 14:53:46 +0000 (UTC) (envelope-from alfa-consult@bk.ru) Received: from zemailov.ru (zemailov.ru [185.118.165.49]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DC511C37 for ; Wed, 16 Dec 2015 14:53:46 +0000 (UTC) (envelope-from alfa-consult@bk.ru) Received: by zemailov.ru with esmtpa (Exim 4.80) id 1a99V8-00054Y-GX; Wed, 16 Dec 2015 15:40:06 +0500 From: "=?utf-8?B?0JDQvdC00YDQtdC5?=" Subject: =?utf-8?B?0JvQuNGG0LXQvdC30LjRjyDQvdCwINC/0YDQvtC00LDQttGDINCw0LvQutC+0LPQvtC70Y8=?= To: "freebsd-ppc@FreeBSD.org" MIME-Version: 1.0 Organization: =?utf-8?B?0JrQkNCg0JDQndCU0JDQqNCa0JjQnQ==?= Date: Wed, 16 Dec 2015 13:40:31 +0300 Message-Id: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 14:53:46 -0000 =20 =D0=9E=D0=9E=D0=9E =C2=AB=D0=90=D0=BB=D1=8C=D1=84=D0=B0-=D0=9A=D0=BE=D0= =BD=D1=81=D0=B0=D0=BB=D1=82=C2=BB =D0=A2=D0=B5=D0=BB: +7 968 498-75-75 +7 968 498-74-74 e-mail: alfa-consult@bk.ru www.alfa-consult.org =20 =20 =D0=BD=D0=B8=D0=B7=D0=BA=D0=B8=D0=B5 =D1=86=D0=B5=D0=BD=D1=8B!!! =D0=9B=D0=B8=D1=86=D0=B5=D0=BD=D0=B7=D0=B8=D1=8F =D0=BD=D0=B0 =D0=BF=D1= =80=D0=BE=D0=B4=D0=B0=D0=B6=D1=83 =D0=B0=D0=BB=D0=BA=D0=BE=D0=B3=D0=BE= =D0=BB=D1=8F =D0=A0=D0=9E=D0=97=D0=9D=D0=98=D0=A7=D0=9D=D0=90=D0=AF =20 =D0=9B=D0=B8=D1=86=D0=B5=D0=BD=D0=B7=D0=B8=D1=8F =D0=BD=D0=B0 =D0=BF=D1= =80=D0=BE=D0=B4=D0=B0=D0=B6=D1=83 =D0=B0=D0=BB=D0=BA=D0=BE=D0=B3=D0=BE= =D0=BB=D1=8F =D0=9E=D0=9F=D0=A2=D0=9E=D0=92=D0=90=D0=AF This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx From owner-freebsd-ppc@freebsd.org Wed Dec 16 21:21:44 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D433EA4ABBD; Wed, 16 Dec 2015 21:21:44 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (unknown [IPv6:2001:4060:1:1001::14:53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B0531382; Wed, 16 Dec 2015 21:21:44 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPS id 0AE14E6068; Wed, 16 Dec 2015 22:21:33 +0100 (CET) Subject: Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1 To: Konstantin Belousov , Mark Millard References: <894D2513-6DE7-4E31-87A5-0529ECDF336C@dsl-only.net> <20151215123640.GG3625@kib.kiev.ua> Cc: FreeBSD Toolchain , FreeBSD PowerPC ML From: Andreas Tobler Message-ID: <5671D5DD.9090808@fgznet.ch> Date: Wed, 16 Dec 2015 22:21:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151215123640.GG3625@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 127.0.1.1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 21:21:44 -0000 On 15.12.15 13:36, Konstantin Belousov wrote: > On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: >> # more main.c int main() { return 0; } >> >> >> >> # ls -l `which cc` -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 >> /usr/bin/cc >> >> # cc --version FreeBSD clang version 3.7.0 (tags/RELEASE_370/final >> 246257) 20150906 Target: powerpc64-unknown-freebsd11.0 Thread >> model: posix >> >> # cc -m32 -mcpu=powerpc main.c # file a.out a.out: ELF 32-bit MSB >> executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically >> linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for >> FreeBSD 11.0 (1100091), not stripped >> >> >> >> By contrast powerpc64-gcc binds the a.out produced to >> /libexec/ld-elf32.so.1 instead: >> >> # ls -l `which gcc` lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 >> /usr/bin/gcc -> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >> >> # gcc --version gcc (FreeBSD Ports Collection for powerpc64) 5.2.0 >> Copyright (C) 2015 Free Software Foundation, Inc. This is free >> software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> # gcc -m32 -mcpu=powerpc main.c # file a.out a.out: ELF 32-bit MSB >> executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically >> linked, interpreter /libexec/ld-elf32.so.1, FreeBSD-style, for >> FreeBSD 11.0 (1100091), not stripped >> > This is a bug in gcc, most likely in the spec file. All FreeBSD ABIs > use either /libexec/ld-elf.so.1 or (for older versions) > /usr/libexec/ld-elf.so.1. This is mine. Taken. Andreas From owner-freebsd-ppc@freebsd.org Fri Dec 18 06:25:53 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1783A4ACE9 for ; Fri, 18 Dec 2015 06:25:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D18AD1E0D for ; Fri, 18 Dec 2015 06:25:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBI6PqK5018406 for ; Fri, 18 Dec 2015 06:25:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205394] lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: lib32's libedit fails to compile, 10 line source shows the problem Date: Fri, 18 Dec 2015 06:25:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bapt@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 06:25:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205394 Bug ID: 205394 Summary: lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: lib32's libedit fails to compile, 10 line source shows the problem Product: Ports & Packages Version: Latest Hardware: ppc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: bapt@FreeBSD.org Reporter: markmi@dsl-only.net CC: freebsd-ppc@FreeBSD.org CC: freebsd-ppc@FreeBSD.org Flags: maintainer-feedback?(bapt@FreeBSD.org) Assignee: bapt@FreeBSD.org The following simple example shows how/why buildworld for lib32 on powerpc64 fails to compile libedit. lang/gcc49, lang/gcc5, and devel/powerpc64-gcc all fail to compile the following "main.c" for -m32 on powerpc64. #include "/usr/include/stddef.h" const wchar_t* test(const wchar_t* p) { return p; } int main(void) { const wchar_t* wcpt = test(L"test"); const wchar_t wcarray[] = L"test"; return 0; } For "gcc49 -m32 main.c" the result is: # gcc49 -m32 main.c main.c: In function 'main': main.c:7:37: warning: passing argument 1 of 'test' from incompatible pointer type const wchar_t* wcpt = test(L"test"); ^ main.c:3:16: note: expected 'const wchar_t *' but argument is of type 'long int *' const wchar_t* test(const wchar_t* p) { return p; } ^ main.c:8:5: error: array of inappropriate type initialized from string constant const wchar_t wcarray[] = L"test"; ^ gcc5 and powerpc64-gcc get the same. A possible fix via an addition to lang/gcc5's and devel/powerpc64-gcc's patch-gcc-freebsd-powerpc64 would look like (tabs likely not preserved): +@@ -304,7 +317,7 @@ + + /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults instead. */ + #undef WCHAR_TYPE +-#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") ++#define WCHAR_TYPE "int" + #undef WCHAR_TYPE_SIZE + #define WCHAR_TYPE_SIZE 32 + It appears that lang/gcc49, lang/gcc5-devel, and lang/gcc6-devel do not have a patch-gcc-freebsd-powerpc64 (yet?). Nor lang/gcc48 or older. At least for gcc49 the content of a patch for this issue could be similar from what I can see. I've not looked at the details for the others. Note: FreeBSD for powerpc64 and its lib32 context define ___wchar_t as int: # grep wchar_t /usr/include/machine/_types.h typedef int ___wchar_t; #define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ #define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@freebsd.org Fri Dec 18 06:59:37 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 875D8A4A13D for ; Fri, 18 Dec 2015 06:59:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76F6B10AE for ; Fri, 18 Dec 2015 06:59:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBI6xbEO090915 for ; Fri, 18 Dec 2015 06:59:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205394] lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: lib32's libedit fails to compile, 10 line source shows the problem Date: Fri, 18 Dec 2015 06:59:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: andreast@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: andreast@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 06:59:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205394 Andreas Tobler changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bapt@FreeBSD.org |andreast@FreeBSD.org CC| |andreast@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@freebsd.org Sat Dec 19 21:42:55 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C659CA4C5A1 for ; Sat, 19 Dec 2015 21:42:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB10A15E9 for ; Sat, 19 Dec 2015 21:42:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBJLgtB9058053 for ; Sat, 19 Dec 2015 21:42:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205440] lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: binds a.out to /libexec/ld-elf32.so.1 instead of /libexec/ld-elf.so.1 Date: Sat, 19 Dec 2015 21:42:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bapt@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 21:42:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205440 Bug ID: 205440 Summary: lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: binds a.out to /libexec/ld-elf32.so.1 instead of /libexec/ld-elf.so.1 Product: Ports & Packages Version: Latest Hardware: ppc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: bapt@FreeBSD.org Reporter: markmi@dsl-only.net CC: freebsd-ppc@FreeBSD.org Assignee: bapt@FreeBSD.org CC: freebsd-ppc@FreeBSD.org Flags: maintainer-feedback?(bapt@FreeBSD.org) [I figured I'd make a formal submittal out of this subject that I'd had exchanges about on some of the mailing lists.] lang/gcc49, lang/gcc5, and devel/powerpc64-gcc all bind built programs to /libexec/ld-elf32.so.1 for -m32 on powerpc64. I'm told it should be /libexec/ld-elf.so.1 instead. Example main.c program processed by gcc49: int main(void) { return 0; } # gcc49 -m32 main.c # file a.out a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1, FreeBSD-style, for FreeBSD 10.2 (1002503), not stripped gcc5 and powerpc64-gcc get the same. A possible fix via an addition to lang/gcc5's and devel/powerpc64-gcc's patch-gcc-freebsd-powerpc64 for the freebsd64.h content would look like (tabs likely not preserved): +@@ -154,7 +167,7 @@ + { "link_os_freebsd_spec32", LINK_OS_FREEBSD_SPEC32 }, \ + { "link_os_freebsd_spec64", LINK_OS_FREEBSD_SPEC64 }, + +-#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1" ++#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf.so.1" + #define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1" + + #define LINK_OS_FREEBSD_SPEC_DEF32 "\ It appears that lang/gcc49, lang/gcc5-devel, and lang/gcc6-devel do not have a patch-gcc-freebsd-powerpc64 (yet?). Nor lang/gcc48 or older. At least for gcc49 the content of a patch for this issue could be similar from what I can see. I've not looked at the details for the others. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@freebsd.org Sat Dec 19 22:19:27 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E24C4A4D7FF for ; Sat, 19 Dec 2015 22:19:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2695118F for ; Sat, 19 Dec 2015 22:19:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBJMJRen056596 for ; Sat, 19 Dec 2015 22:19:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205440] lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: binds a.out to /libexec/ld-elf32.so.1 instead of /libexec/ld-elf.so.1 Date: Sat, 19 Dec 2015 22:19:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: andreast@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: andreast@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 22:19:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205440 Andreas Tobler changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bapt@FreeBSD.org |andreast@FreeBSD.org CC| |andreast@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@freebsd.org Sat Dec 19 22:23:07 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86B18A4DA5E for ; Sat, 19 Dec 2015 22:23:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7703B1446 for ; Sat, 19 Dec 2015 22:23:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBJMN7Qt067324 for ; Sat, 19 Dec 2015 22:23:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205394] lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: lib32's libedit fails to compile, 10 line source shows the problem Date: Sat, 19 Dec 2015 22:23:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: andreast@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: andreast@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 22:23:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205394 --- Comment #1 from Andreas Tobler --- This one is fixed upstream. Port fix for gcc-5.3 will follow once I'm ready. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@freebsd.org Sat Dec 19 22:24:41 2015 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC200A4DB1C for ; Sat, 19 Dec 2015 22:24:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC66D14C6 for ; Sat, 19 Dec 2015 22:24:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBJMOf7a069119 for ; Sat, 19 Dec 2015 22:24:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205440] lang/gcc49, lang/gcc5, devel/powerpc64-gcc on powerpc64: binds a.out to /libexec/ld-elf32.so.1 instead of /libexec/ld-elf.so.1 Date: Sat, 19 Dec 2015 22:24:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: andreast@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: andreast@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 22:24:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205440 --- Comment #1 from Andreas Tobler --- Currently all active gcc branches are broken for FreeBSD powerpc64. Once the break is fixed I'll apply a suitable fix. It'll take some time. -- You are receiving this mail because: You are on the CC list for the bug.