[musl] Powerpc Linux 'scv' system call ABI proposal take 2

Segher Boessenkool segher at kernel.crashing.org
Fri Apr 17 11:48:31 AEST 2020


On Thu, Apr 16, 2020 at 08:34:42PM -0400, Rich Felker wrote:
> On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote:
> > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote:
> > > > I think my choice would be just making the inline syscall be a single
> > > > call insn to an asm source file that out-of-lines the loading of TOC
> > > > pointer and call through it or branch based on hwcap so that it's not
> > > > repeated all over the place.
> > > 
> > > I don't know how problematic control flow out of an inline asm is on
> > > POWER.  But this is basically the -moutline-atomics approach.
> > 
> > Control flow out of inline asm (other than with "asm goto") is not
> > allowed at all, just like on any other target (and will not work in
> > practice, either -- just like on any other target).  But the suggestion
> > was to use actual assembler code, not inline asm?
> 
> Calling it control flow out of inline asm is something of a misnomer.
> The enclosing state is not discarded or altered; the asm statement
> exits normally, reaching the next instruction in the enclosing
> block/function as soon as the call from the asm statement returns,
> with all register/clobber constraints satisfied.

Ah.  That should always Just Work, then -- our ABIs guarantee you can.

> Control flow out of inline asm would be more like longjmp, and it can
> be valid -- for instance, you can implement coroutines this way
> (assuming you switch stack correctly) or do longjmp this way (jumping
> to the location saved by setjmp). But it's not what'd be happening
> here.

Yeah, you cannot do that in C, not without making assumptions about what
machine code the compiler generates.  GCC explicitly disallows it, too:

     'asm' statements may not perform jumps into other 'asm' statements,
     only to the listed GOTOLABELS.  GCC's optimizers do not know about
     other jumps; therefore they cannot take account of them when
     deciding how to optimize.


Segher


More information about the Linuxppc-dev mailing list