This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 28 Jan 2020 17:04:49 +0100
Florian Weimer <fweimer@redhat.com> wrote:

> * Segher Boessenkool:
> 
> >> > 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?
> 
> As far as I knowm there isn't a CFI directive that allows us to
> restore the CFI state at the end of the inline assembly.  If we say
> that LR is stored in a different register than what the rest of the
> function uses, that would lead to incorrect CFI after the exit of the
> inline assembler fragment.
> 
> At least that's what I think.  Compilers aren't really my thing.
> 
> >
> >> >> - 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).
> 
> But GCC doesn't expose them as integers to C code, so you can't do
> much without them.
> 
> >> >> - 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.
> 
> Sorry for the confusion.  Is POWER9 running kernels which are not
> 64-bit LE really a thing in practice, though?

yes, there are Linux distros under active development that run in big
endian on Power9 systems. They are likely niche, but they are there.
FreeBSD is still big endian only (FWIW).


		Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]