Bug 92769 - Powerpc: No way to set CR0[SO] on function return
Summary: Powerpc: No way to set CR0[SO] on function return
Status: WAITING
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-03 13:18 UTC by Christophe Leroy
Modified: 2020-01-12 09:17 UTC (History)
1 user (show)

See Also:
Host:
Target: powerpc
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-12-11 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Leroy 2019-12-03 13:18:25 UTC
Linux system calls and Linux VDSO calls require the error status to be reflected through SO bit of CR0 register on function return.

There is no way to do that from C functions. This requires to add Assembly trampoline functions just for that, with all associated drawbacks (adding a stack frame to save LR, etc ...)

Would it be possible to add to builtin-functions which would set/clear SO on function return ?

Something like:
- __builtin_ppc_return_with_so_set()
- __builtin_ppc_return_with_so_cleared()
Comment 1 Segher Boessenkool 2019-12-11 17:30:26 UTC
CR0 is volatile in all our ABIs, so this is impossible to support from
a C function without defining a new ABI first.
Comment 2 Christophe Leroy 2019-12-11 17:36:18 UTC
But CR0 being volatile doesn't prevent GCC to set/clr its SO bit just before branching to LR as the ASM functions do, does it ?

In our ABIs, r3 is also volatile in our ABIs, it doesn't prevent using it as function return.
Comment 3 Segher Boessenkool 2019-12-11 18:50:46 UTC
(In reply to Christophe Leroy from comment #2)
> But CR0 being volatile doesn't prevent GCC to set/clr its SO bit just before
> branching to LR as the ASM functions do, does it ?

Not at all, no.  But e.g. (linker-generated) glue code is free to clobber R0!

> In our ABIs, r3 is also volatile in our ABIs, it doesn't prevent using it as
> function return.



No, R3 is defined to be used as the return value.  CR0 is not.
Comment 4 Andrew Pinski 2020-01-12 05:52:16 UTC
>Linux system calls and Linux VDSO calls 

System calls, I can understand  But why is it required by VDSO calls too?  That seems backwards and also means VDSO functions are not the same ABI as normal functions.
Comment 5 Segher Boessenkool 2020-01-12 08:49:16 UTC
(In reply to Andrew Pinski from comment #4)
> >Linux system calls and Linux VDSO calls 
> 
> System calls, I can understand  But why is it required by VDSO calls too? 
> That seems backwards and also means VDSO functions are not the same ABI as
> normal functions.

It is how it is, we have to implement it whatever strange things are required ;-)

Part of the reason may be that vdso calls *are* a lot like system calls; the
fallback for an unimplemented vdso call is the corresponding system call, for
example.
Comment 6 Andrew Pinski 2020-01-12 09:17:03 UTC
(In reply to Segher Boessenkool from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > >Linux system calls and Linux VDSO calls 
> > 
> > System calls, I can understand  But why is it required by VDSO calls too? 
> > That seems backwards and also means VDSO functions are not the same ABI as
> > normal functions.
> 
> It is how it is, we have to implement it whatever strange things are
> required ;-)
> 
> Part of the reason may be that vdso calls *are* a lot like system calls; the
> fallback for an unimplemented vdso call is the corresponding system call, for
> example.

That is fine but they still should be different ABIs.  Anything else seems broken and wrong.