public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: "Kewen.Lin" <linkw@linux.ibm.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]
Date: Thu, 29 Sep 2022 13:50:17 -0500	[thread overview]
Message-ID: <20220929185017.GC25951@gate.crashing.org> (raw)
In-Reply-To: <E5508A9F-20BE-4031-9A55-5D2845497705@sandoe.co.uk>

On Thu, Sep 29, 2022 at 07:33:14PM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 18:18, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
> >>> On 28 Sep 2022, at 22:30, Segher Boessenkool <segher@kernel.crashing.org> 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

  reply	other threads:[~2022-09-29 18:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28  5:30 Kewen.Lin
2022-09-28  6:37 ` Iain Sandoe
2022-09-28 16:18   ` Iain Sandoe
2022-09-28 19:09     ` Iain Sandoe
2022-09-29  5:45       ` Kewen.Lin
2022-09-29  8:16         ` Iain Sandoe
2022-09-29  9:12           ` Kewen.Lin
2022-09-29 16:14             ` Iain Sandoe
2022-09-29 17:04           ` Segher Boessenkool
2022-09-29 18:25             ` Iain Sandoe
2022-09-29 18:37               ` Segher Boessenkool
2022-09-30  9:26                 ` Kewen.Lin
2022-09-29 17:11         ` Segher Boessenkool
2022-09-30 12:15           ` Kewen.Lin
2022-10-03 21:15             ` Segher Boessenkool
2022-10-10  2:15               ` Kewen.Lin
2022-10-10 13:58                 ` Segher Boessenkool
2022-10-12  8:26                   ` Kewen.Lin
2022-09-28 21:30     ` Segher Boessenkool
2022-09-28 23:04       ` Iain Sandoe
2022-09-28 23:16         ` Iain Sandoe
2022-09-29 17:26           ` Segher Boessenkool
2022-09-29 17:18         ` Segher Boessenkool
2022-09-29 18:33           ` Iain Sandoe
2022-09-29 18:50             ` Segher Boessenkool [this message]
2022-09-28 22:04 ` Segher Boessenkool
2022-09-29  6:16   ` Kewen.Lin
2022-09-29 18:56     ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220929185017.GC25951@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    --cc=linkw@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).