From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id 7869438708F9; Tue, 2 Jun 2020 02:03:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7869438708F9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=octaforge.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=daniel@octaforge.org Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A089F5C0065; Mon, 1 Jun 2020 22:03:55 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 01 Jun 2020 22:03:55 -0400 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=1U+TpcmElryzdORJ+uEwkyNjG0LM xX7jof7K6babZzE=; b=QB0nIUcGKZ1RrgKVU0teyyu41q54zFycVMeY/nUsAW1q C0zzj4bdBvz+pWAVv+Hgg2Ike+bOIKmve4UIYdrYNY1dxgLBgmUzvialnoLc8CUG PNTqUZBoshHZ1vp8/cvu61NMBOJOzQpoT8PVssfS+1Tjcc24HSMkMg780ZQzYxyw JdJvotafa1f+do1qoUQ27o96lNZECnMk98MitH9tCK98UaNAimRdlXbagh5dDUeU uUMnORGVR5HUoWnOJuyEGm0j3kPe01px39z4fQDmgHZ3c0uP7+sokI0sL1aoAs83 j8U/VsJijiPqw2vhwy2pLsYEyL8guMezPhsv1OJR0w== 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=1U+Tpc mElryzdORJ+uEwkyNjG0LMxX7jof7K6babZzE=; b=NZo7qmTRpOOr8H9cfJm5z0 h5VEeHrfAP+hB1lvBz67b5en3axT9IYiOETgH256ArU5+DyStFLkkXFH8/oXGFPc 7+hKpWxPPEWHw9fnQww/Ta+wdvfCm2jzoJb1kmL/GwYydjfRkdfZVXIqS/mYY4vK pN1tWH79PgyuBlT/mNomfe+Gxsp5ZTKsuSN2L94GSEx8RN5jliqwZSeOW/fGeQMm VlqoDIkn/aEpRhrbqRM3sI1Lgf5nVatTXPKgxlcKnXweObmkVLEyhibzsuCTSIOT X7RT4QnsRVOu23uMmcyRT3Yp0/Xvb+jaCw08CnzAZhglrqhBMDtxQl0bgsou6KvQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefiedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghn ihgvlhcumfholhgvshgrfdcuoegurghnihgvlhesohgtthgrfhhorhhgvgdrohhrgheqne cuggftrfgrthhtvghrnhepueelgeeljeeigeeghefgtddtveeuhedvheeuteeiveetledu vdevvdfgtdeigfdvnecuffhomhgrihhnpehsohhurhgtvgifrghrvgdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurghnihgvlhes ohgtthgrfhhorhhgvgdrohhrgh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 24EADC200A4; Mon, 1 Jun 2020 22:03:54 -0400 (EDT) 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: <20200602014227.GM31009@gate.crashing.org> References: <2047231.C4sosBPzcN@sheen> <20200602014227.GM31009@gate.crashing.org> Date: Tue, 02 Jun 2020 04:03:33 +0200 From: "Daniel Kolesa" To: "Segher Boessenkool" , "Joseph Myers" Cc: "Will Springer" , libc-alpha@sourceware.org, eery@paperfox.es, musl@lists.openwall.com, "Palmer Dabbelt via binutils" , "via libc-dev" , linuxppc-dev@lists.ozlabs.org Subject: Re: ppc64le and 32-bit LE userland compatibility Content-Type: text/plain X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 02:03:59 -0000 On Tue, Jun 2, 2020, at 03:42, Segher Boessenkool wrote: > Hi Joseph, > > On Mon, Jun 01, 2020 at 09:28:25PM +0000, Joseph Myers wrote: > > On Fri, 29 May 2020, Will Springer via Binutils wrote: > > > > > Hey all, a couple of us over in #talos-workstation on freenode have been > > > working on an effort to bring up a Linux PowerPC userland that runs in 32-bit > > > little-endian mode, aka ppcle. As far as we can tell, no ABI has ever been > > > designated for this (unless you count the patchset from a decade ago [1]), so > > > it's pretty much uncharted territory as far as Linux is concerned. We want to > > > sync up with libc and the relevant kernel folks to establish the best path > > > forward. > > > > As a general comment on the glibc side of things, if this is considered > > like a new port, and it probably is, the same principles that apply to new > > ports apply here. > > > > There's a general discussion at > > , although much of that is > > only applicable when adding new CPU architecture support. More specific > > points include that new 32-bit ports should default to 64-bit time and > > file offsets from the start, with no support for 32-bit time or offsets > > (meaning that if you want to use this with some kind of library call > > translation, the library call translation will need to deal with > > corresponding type size conversions). > > Either that, or use the same as BE 32-bit PowerPC Linux, I'd say (it > won't make things worse, and if it is easier?) But preferably the > newer, better, thing of course :-) > > > And a new port should not be added > > that uses the IBM long double format. You can use IEEE binary128 long > > double, possibly with an ABI similar to that used on powerpc64le, or can > > use long double = double, but should not support IBM long double, and > > preferably should only have one long double format rather than using the > > glibc support for building with different options resulting in functions > > for different long double formats being called. > > You cannot use IEEE QP float ("binary128") here, but more on that in a > later post. > > (I so very much agree about the problems having more than one long > double format -- on the other hand, you'll just share it with BE, and > with the existing powerpcle-linux (sup)port). Well, it'd be nice to use the opportunity to ditch the IBM long doubles altogether, since these get in the way for me in various places (for instance, GCC still can't constant-fold them, which breaks on constexpr in C++, as well as makes it impossible to e.g. enable the runtime/standard library for GDC in GCC as that heavily relies on the `real` type in D, which maps directly to `long double` and druntime/phobos heavily relies on constant folding of the `real` type being functional; there are also assorted libraries and applications in the common userland that don't like the IBM format for one reason or another) That said, that's also problematic: 1) ppc64le is going to newly use IEEE754 binary128, so we're all good there - baseline mandates VSX, so at least passing them is fine, which is the important thing (actual binary128 instructions came with ISA 3.0 but that can be detected at runtime, at least in glibc) - ibm128 is then implemented via symvers/compat, which is fine. 2) ppc64 for now uses IBM 128-bit long double, so it's problematic. I don't care about ELFv1, as it's legacy and has tons of drawbacks on its own, and there's a whole legacy ecosystem relying on it; that said, a new ELFv2 port (let's say, with ld64.so.3 dynamic linker) could easily default to another long double format, without worrying about compat - I propose this format to be binary64, as it's already used by musl on BE/64 (allows projects such as `gcompat` to work) and thus is already implemented in all toolchains we care about and can easily be flipped on, and is fully compatible with all CPUs that can run ppc64 code, even without VMX/VSX 3) ppcle would be a new port (let's say ld.so.2), so it could default to a new format; binary64 would be good 4) that leaves ppc32/BE, which would be the only outlier - while I could probably implement compat in much the same way as ppc64le does with binary128 (bump symvers for math symbols, leave older symvers for existing binaries, change defaults), this would be divergent from the existing port; glibc/IBM probably won't want to switch this, and while I would definitely like to, maintaining a divergent downstream patchset seems non-ideal. There is some basis for this - glibc did use to use binary64 on ppc32 and ppc64 BE in the past, and the compatibility symbols are still there under the old symvers, but not quite sure what to do there. > > > Segher > Daniel