From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 65692385C418 for ; Thu, 29 Sep 2022 18:51:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 65692385C418 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=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 28TIoHJ3006448; Thu, 29 Sep 2022 13:50:17 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 28TIoHDg006447; Thu, 29 Sep 2022 13:50:17 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 29 Sep 2022 13:50:17 -0500 From: Segher Boessenkool To: Iain Sandoe Cc: "Kewen.Lin" , GCC Patches Subject: Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680] Message-ID: <20220929185017.GC25951@gate.crashing.org> References: <9d9f1f43-b528-387d-45a7-1d89400de0fc@linux.ibm.com> <5B4DCBBB-3237-4A9F-ACCA-6669DE6905B8@sandoe.co.uk> <20220928213049.GU25951@gate.crashing.org> <20220929171858.GZ25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Sep 29, 2022 at 07:33:14PM +0100, Iain Sandoe wrote: > > On 29 Sep 2022, at 18:18, Segher Boessenkool wrote: > > On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote: > >>> On 28 Sep 2022, at 22:30, Segher Boessenkool wrote: > >>> That works on Linux as well. What still does not work is user-mode > >>> context switches in 32-bit processes (so setjmp and getcontext stuff). > >> > >> AFAIU the Darwin impl. it is the same - the user context only contains 32b > >> register images. > > > > Huh, I thought Darwin did this properly. > > > >> Since one can only use the feature between function calls, > > > > You still have to preserve the non-volatile GPRs. All 64 bits of it. > > The OS does do that - e.g. on an interrupt .. but AFAIR, the user-visible mcontext > in a 32b process only shows the lower 32 bits. AFAIR the Darwin setjmp/longjmp and setcontext/getcontext do the full 64-bit registers. > ( i’d better stop making too many assertions here from memory, ;) ) Yeah, my memory might not work so well either, for stuff 20 years back! > > But that is not how GCC with -mpowerpc64 works: the calling convention > > is the usual 32-bit one, but the functions are 64-bit otherwise; it uses > > all 64 bits of GPRs everywhere except in function calls. > > I think we said the same thing with different words. > > The CC is unchanged (so that we can only use 64b insns between calls, since > the upper 32b of callee-saved regs are not preserved). But non-volatile GPRs (r21..r31 say) retain the full 64 bits over calls. This needs to be handled by those libc routines, to be compliant at all. Of course a lot of code will work fine, for example the whole GCC testsuite, if you only have the kernel context switches preserve the whole registers. But almost all code that uses setjmp (which is done by some libraries btw, behind the back of the user / programmer) fails spectacularly. Segher