powerpc Linux scv support and scv system call ABI proposal
Segher Boessenkool
segher at kernel.crashing.org
Wed Jan 29 02:40:26 AEDT 2020
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
More information about the Linuxppc-dev
mailing list