On Thu, Sep 29, 2022 at 07:33:14PM +0100, Iain Sandoe wrote: > > On 29 Sep 2022, at 18:18, Segher Boessenkool <seg...@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 <seg...@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
