Re: powerpc Linux scv support and scv system call ABI proposal

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Jan 29, 2020 at 12:05:40AM +1000, Nicholas Piggin wrote:
> Florian Weimer's on January 28, 2020 11:09 pm:
> > But I don't think we are so lucky for the inline system calls.  GCC
> > recognizes an "lr" clobber with inline asm (even though it is not
> > documented), but it generates rather strange assembler output as a
> > result:

> > 	std 0,16(1)
> > 	ori 2,2,0
> > 	ld 0,16(1)

> > That's with GCC 8.3 at -O2.  I don't understand what the ori is about.
> 
> ori 2,2,0 is the group terminating nop hint for POWER8 type cores
> which had dispatch grouping rules.

Yup.  GCC generates that here to force the load into a different
scheduling group than the corresponding store is, because that otherwise
would cause very expensive pipeline flushes.  It does that if it knows it
is the same address (like here).

> > I don't think we can save LR in a regular register around the system
> > call, explicitly in the inline asm statement, because we still have to
> > generate proper unwinding information using CFI directives, something
> > that you cannot do from within the asm statement.

Why not?

> >> - Error handling: use of CR0[SO] to indicate error requires a mtcr / mtocr
> >>   instruction on the kernel side, and it is currently not implemented well
> >>   in glibc, requiring a mfcr (mfocr should be possible and asm goto support
> >>   would allow a better implementation). Is it worth continuing this style of
> >>   error handling? Or just move to -ve return means error? Using a different
> >>   bit would allow the kernel to piggy back the CR return code setting with
> >>   a test for the error case exit.
> > 
> > GCC does not model the condition registers,

Huh?  It does model the condition register, as 8 registers in GCC's
internal model (one each for CR0..CR7).

There is no way to use CR0 across function calls, with our ABIs: it is
a volatile register.

GCC does not model the SO bits in the CR fields.

If the calling convention would only use registers GCC *does* know
about, we can have a builtin for this, so that you can get better
inlining etc., no need for an assembler wrapper.

> > But the kernel uses the -errno convention internally, so I think it
> > would make sense to pass this to userspace and not convert back and
> > forth.  This would align with what most of the architectures do, and
> > also avoids the GCC oddity.
> 
> Yes I would be interested in opinions for this option. It seems like
> matching other architectures is a good idea. Maybe there are some
> reasons not to.

Agreed with you both here.

> >> - Should this be for 64-bit only? 'scv 1' could be reserved for 32-bit
> >>   calls if there was interest in developing an ABI for 32-bit programs.
> >>   Marginal benefit in avoiding compat syscall selection.
> > 
> > We don't have an ELFv2 ABI for 32-bit.  I doubt it makes sense to
> > provide an ELFv1 port for this given that it's POWER9-specific.

We *do* have a 32-bit LE ABI.  And ELFv1 is not 32-bit either.  Please
don't confuse these things :-)

The 64-bit LE kernel does not really support 32-bit userland (or BE
userland), *that* is what you want to say.

> > From the glibc perspective, the major question is how we handle run-time
> > selection of the system call instruction sequence.

Well, if it is inlined you don't have this problem either!  :-)


Segher