From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32299 invoked from network); 4 Jun 2020 20:40:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Jun 2020 20:40:11 -0000 Received: (qmail 18004 invoked by uid 550); 4 Jun 2020 20:40:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17986 invoked from network); 4 Jun 2020 20:40:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=octaforge.org; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=MUHn5s5Nt7GGkqN++AgnN3kqO2g2 mXg1y0pbVUfJVho=; b=RAxXaGYPaDHVlTsCg7c6bk5/hdnUFoTM0zWfQeMAuVN+ sQM7ylaBZHR0uZVXv1pGL5DRyspm2+zddgbcaBp+Z7Kh8/pJNpDjvZV69YvWXjG8 jlvrD7/kH3N3j9ejwQsx0bOFagRLyJlWE1JzCLIZeMhWD5SBKbSPcL7iy6LvnuK0 ZFxIPmy+6FDpen1sZAi36Wk9/yHLvR47YID51dPLUYk5Vq573/D9tMgE39/5/Ygr knwjcs8nnl9J4Ypv3o05+TNgZqbKgLlQpkWGu1anVotVj47vbEIkF9DIx2lgExia mXO7ORtTxmihDihAEC5Y0bBuIO/smlcNPfFITeMzfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MUHn5s 5Nt7GGkqN++AgnN3kqO2g2mXg1y0pbVUfJVho=; b=bn/EpETPJIpWcqB1b3Uee1 +fK8nlBBDfXpN6RKNORw0k1TLX/xwxSQMhZ0y9I4ceMzbD11ddApv2U9/QNCnlca aGdGVsPxw3pGpYxvM/nCyeTSKpmMkr7+4EzGbYa4emJuc5q7UuTD7Uu/sdM2zYcd 9Tk/qEpAkoGQqxJalQRlJusMdhvE8593YNYffV7Z/tOyjAeswr0AkDglYa5d20LE D7I9XMIE1ES3XX7hyHImRIXhc92i0FVDwuVn6m/lHz9wXfRtsrjwFDT7oazfMuHA UvP3etZG+NcteyRJd68B8X6tv/dS2pUpiUwTedkRqASM3t4GVTGC/cgGvYCwqPcA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeguddgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfffgr nhhivghlucfmohhlvghsrgdfuceouggrnhhivghlsehotghtrghfohhrghgvrdhorhhgqe enucggtffrrghtthgvrhhnpeeivedvvdejheeitddvlefgueeihffgtedvuefhffethedu udffgfduhfffhfelfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegurghnihgvlhesohgtthgrfhhorhhgvgdrohhrgh X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: In-Reply-To: <20200604173312.GI31009@gate.crashing.org> References: <2047231.C4sosBPzcN@sheen> <20200602142337.GS25173@kitsune.suse.cz> <3aeb6dfe-ae23-42f9-ac23-16be6b54a850@www.fastmail.com> <20200604171232.GG31009@gate.crashing.org> <20200604171844.GO1079@brightrain.aerifal.cx> <20200604173312.GI31009@gate.crashing.org> Date: Thu, 04 Jun 2020 22:39:30 +0200 From: "Daniel Kolesa" To: "Segher Boessenkool" , "Rich Felker" Cc: =?UTF-8?Q?Michal_Such=C3=A1nek?= , "Joseph Myers" , libc-alpha@sourceware.org, eery@paperfox.es, musl@lists.openwall.com, "Will Springer" , "Palmer Dabbelt via binutils" , "via libc-dev" , linuxppc-dev@lists.ozlabs.org Content-Type: text/plain Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility On Thu, Jun 4, 2020, at 19:33, Segher Boessenkool wrote: > On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote: > > On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote: > > > On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote: > > > > well, ppc64le already cannot be run on those, as far as I know (I > > > > don't think it's possible to build ppc64le userland without VSX in > > > > any configuration) > > > > > > VSX is required by the ELFv2 ABI: > > > > > > """ > > > Specifically, to use this ABI and ABI-compliant programs, OpenPOWER- > > > compliant processors must implement the following categories: > > > > This is not actually ABI but IBM policy laundered into an ABI > > document, which musl does not honor. > > It is the ABI. If you think it should be different, make your own ABI, > don't pretend the existing ABI is different than what it is. Thank you. > Well then - in that case, what do you suggest that I do? Void currently ships an ELFv2 (or apparently not, I guess) 64-bit big endian port that works on 970/G5 up. It is important to me that it stays that way (a large amount of users are running 970s, so introducing a VSX dependency means I might as well abandon the port entirely). It currently works out of box - there are no changes required in glibc, and nearly the entire userland builds and works (about ~11500 out of ~12000 software packages, those that don't work either don't work on ppc64le either, or have issues related to endianness, or some other unrelated reason). I'd like to eventually get this into a state where I don't have to worry about glibc arbitrarily breaking it - which means it would be necessary to stabilize it upstream. While I can probably maintain a downstream patchset when it comes to it, I'd much prefer if I didn't have to - but this sounds like an official ELFv2 glibc BE port would be impossible unless the VSX requirement (and thus IEEE 128-bit long double and so on) was in place, which would defeat the point of the port. Is there *any* way I can take that would make upstreams of all parts of the toolchain happy? I explicitly don't want to go back to ELFv1. While at it, I'd like to transition to ld64 long double format, to match musl and improve software compatibility, which I feel will raise more objections from IBM side. > > Segher > Daniel