From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D005D1F55B for ; Tue, 2 Jun 2020 01:58:30 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8BD1A383F86D; Tue, 2 Jun 2020 01:58:29 +0000 (GMT) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id A308B38708F9; Tue, 2 Jun 2020 01:58:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A308B38708F9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 0521w3Ot014392; Mon, 1 Jun 2020 20:58:03 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 0521w2aI014389; Mon, 1 Jun 2020 20:58:02 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 1 Jun 2020 20:58:02 -0500 From: Segher Boessenkool To: Daniel Kolesa Subject: Re: ppc64le and 32-bit LE userland compatibility Message-ID: <20200602015802.GN31009@gate.crashing.org> References: <2047231.C4sosBPzcN@sheen> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i 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: , Cc: 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, Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Tue, Jun 02, 2020 at 01:26:37AM +0200, Daniel Kolesa wrote: > On Mon, Jun 1, 2020, at 23:28, Joseph Myers 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. That's right. Except it isn't an "official" existing port, never has been "officially" supported. > 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 64-bit long double, though (musl already does, on all ppc ports). The current IEEE QP float support requires VSX for its emulation, yes (possibly even Power8?) As Mike reminded me today, it also requires __int128 support, which rules out anything 32-bit currently. Without that restriction, we could just make QP float passed in GPRs (use the ABIs for any struct passed that way), and that'll just work out with all ABIs, older or not. > While we're at long double, I'd actually be interested in transitioning the existing big endian ports in Void (64-bit and 32-bit, neither has VSX baseline requirement in my case) to using 64-bit long double, abandoning the IBM format altogether (little endian will transition to 128-bit IEEE long double once it's ready on your side, as that assumes POWER8 baseline which includes VSX). I recommend new ports that cannot jump to IEEE QP float directly to use long double == double for the time being, avoiding the extra complications that IBM double double would bring. But you'll still have a transition to IEEE 128 if you ever want to go there. But if you already use double-double, I don't know if the cost changing away from that is worth it now. > What would be the best way for me to proceed with that? I actually experimented with this, using the old glibc compat symbols from pre-ibm128 times, and I mostly had it working, except I haven't managed to find a way to switch the default symbols to 64-bit ones, which is problematic as linking everything against nldbl_nonshared is fragile and potentially quirky (breaks dlsym, function pointer equality across libraries, etc). Yup. "Rebuild the world" works :-/ I don't have any better advice, nothing you cannot figure out yourself. > 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? (I don't talk for glibc). The first thing needed is for "us" to have faith in it. That starts with seeing test results for the testsuites! (Something similar goes for the GCC port -- there is no official support for BE ELFv2, but of course it does work, and if we get test results we may keep it that way, hint hint :-) ) Segher