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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 30856 invoked from network); 2 Jun 2020 00:11:39 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2020 00:11:39 -0000 Received: (qmail 7634 invoked by uid 550); 2 Jun 2020 00:11:37 -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 7593 invoked from network); 2 Jun 2020 00:11:36 -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=nE9WDmKoox2eCpfIvJhS+C7GKX9i IDXJZVhx4DlAhyE=; b=pkU/tkxXCawfpz5wTZ+vipgEjrEEjMydL+GFQ28BMkf4 of5RNeZrlQyXkUkUZYaE9I16Knp/8tK54M80QrQ6bGwmvISTwiVmVPyLVHZRfxNU kkxlRWx+iZj+4Cbo3ABBbeg9vHv3E5o58zp1wyKHyDf5yKs907qbpBqLmg7z/ldS 3hX/do8AUHV7rNHszvhO76EKC0/XRsiwxv0pxlbBEISJue59QTc41dBvql6KonHY dzICLz5P8Njr68GuVrpBd8lxZ9j0YbbSX12r0EE88dz/FZJZ6VNUqh5/dsoAH3rL gMeYTrmIVzM/3rom0S/xT1+Nzy7P/zLk/y2f3VZIBQ== 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=nE9WDm Koox2eCpfIvJhS+C7GKX9iIDXJZVhx4DlAhyE=; b=d/+azhY7gvIKJXI9LwuIWs Db8MM2uk5ddccVqgG5Swy/0nV3bx5hCw+eBZT3sPASv1qmqjcWSMfCtEyJhAFvON 7I0fzV4HunpjWA2yWlq3kq1C2kZTOLjm5h32+OMNmB3bXzgzF/5/J3JWZtWwL42O foqJFee3NzyuE3KBt3383RAGi2VpBGtu7xKB4lN4XgK9dFS7kvxPS8Um5yfAdME3 h+RSbAqpiayVERzVg2YwhR8pZy7qJgSQHhSFjp0+Z+HEXYVHGn4wwadBS77v69Wn tFz5KZ3xnXKEwtLMVJMFqDc/Lm5hHikG9KbQvdWGKdiH+48LQC3fcf6pjFOYCdCQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefiedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghn ihgvlhcumfholhgvshgrfdcuoegurghnihgvlhesohgtthgrfhhorhhgvgdrohhrgheqne cuggftrfgrthhtvghrnhepueelgeeljeeigeeghefgtddtveeuhedvheeuteeiveetledu vdevvdfgtdeigfdvnecuffhomhgrihhnpehsohhurhgtvgifrghrvgdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurghnihgvlhes ohgtthgrfhhorhhgvgdrohhrgh 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: References: <2047231.C4sosBPzcN@sheen> Date: Tue, 02 Jun 2020 02:11:03 +0200 From: "Daniel Kolesa" To: "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 Content-Type: text/plain Subject: [musl] Re: ppc64le and 32-bit LE userland compatibility On Tue, Jun 2, 2020, at 01:45, Joseph Myers wrote: > On Tue, 2 Jun 2020, Daniel Kolesa wrote: > > > Are you sure this would be a new port? Glibc already works in this > > combination, as it seems to me it'd be best if it was just a variant of > > the existing 32-bit PowerPC port, sharing most conventions besides > > endianness with the BE port. > > The supported glibc ABIs are listed at > . This would be a new ABI, > which should have a new ABI-and-architecture-specific dynamic linker name > (all new ports are expected to have a unique dynamic linker name for each > ABI, to support systems using multiarch directory arrangements), new > symbol versions and avoid legacy features such as 32-bit time or offsets > or IBM long double. > > > 128-bit IEEE long double would not work, since that relies on VSX being > > present (gcc will explicitly complain if it's not). I'd be all for using > > The minimum supported architecture for powerpc64le (POWER8) has VSX. My > understanding was that the suggestion was for 32-bit userspace to run > under powerpc64le kernels running on POWER8 or later, meaning that such a > 32-bit LE port, and any ABI designed for such a port, can assume VSX is > available. Or does VSX not work, at the hardware level, for 32-bit > POWER8? (In which case you could pick another ABI for binary128 argument > passing and return.) POWER8 may have VSX (well, actually POWER7 and newer has VSX and can run LE, but glibc does not support this, musl potentially does), but the overall assumption here is that the resulting binaries should eventually not be limited to being just userspace under ppc64le, but should be runnable on a native kernel as well, which should not be limited to any particular baseline other than just PowerPC. While it should in theory be possible to do IEEE ldbl128 using a different ABI, I don't really see any benefit in this - for one, the baseline hardware doesn't support on any level, it would mean further complicating the ABI, and it would require explicit support in the compiler, which currently doesn't exist. Using 64-bit long doubles sounds like a much better way out to me. > > > There is also one more thing while we're at this. The 64-bit big endian > > Void port uses the ELFv2 ABI, even on glibc. This is not officially > > supported on glibc as far as I can tell, but it does work out of box, > > without any patching (things in general match little endian then, i.e. > > ld64.so.2 etc, but they're big endian). Is there any chance of making > > that support official? > > If you want to support ELFv2 for 64-bit big endian in glibc, again that > should have a unique dynamic linker name, new symbol versions, only > binary128 long double, etc. - avoid all the legacy aspects of the existing > ELFv1 port rather than selectively saying that "ELFv1" itself is the only > legacy aspect and keeping the others (when it's the others that are > actually more problematic in glibc). Again, the BE port cannot use binary128 long double, at least not with the same ABI as on POWER8, since it runs on all 64-bit PowerPC systems starting with 970 (G5, and potentially even POWER4 if built without AltiVec). Unique dynamic linker names are complicated, since as it is, glibc uses ld64.so.1 for ELFv1, and ld64.so.2 for ELFv2. (on 32-bit PowerPC, it's ld.so.1, and uses the SVR4 ABI which is not related to either the AIX/ELFv1 nor the ELFv2 ABIs) If we were to introduce new ports, what would those use? ld64.so.3 for BE/v2? ld.so.2 for LE/32-bit? I can see the reason for a new dynamic linker name though (multi-arch setups). However, the effective difference between the ports would be rather minimal, if any, as far as I can see. As I already said, we have a whole glibc/ELFv2/BE system, with nearly all of the existing Linux userland covered by the distro, and there haven't been any issues whatsoever. > > -- > Joseph S. Myers > joseph@codesourcery.com > Daniel