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
