Florian Weimer's on January 29, 2020 1:58 am: > * Nicholas Piggin: > >> That gets the LR save/restore right when we're also using r0. > > Yes, I agree it looks good. Nice. > >>> 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. > > If there were a POWER-specific system call that uses all result bits and > doesn't have room for the 4096 error states (or an error number that's > outside that range), that would be a blocker. I can't find such a > system call wrapped in the glibc sources.
Nothing apparent in the kernel sources either. > musl's inline syscalls always > convert the errno state to -errno, so it's not possible to use such a > system call there. > >>>> - 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. >> >> Okay. There's no reason not to enable this for BE, at least for the >> kernel it's no additional work so it probably remains enabled (unless >> there is something really good we could do with the ABI if we exclude >> ELFv1 but I don't see anything). >> >> But if glibc only builds for ELFv2 support that's probably reasonable. > > To be clear, we still support ELFv1 for POWER, but given that this > feature is POWER9 and later, I expect the number of users benefiting > from 32-bit support (or ELFv1 and thus big-endian support) to be quite > small. > > Especially if we go the conditional branch route, I would restrict this > to ELFv2 in glibc, at least for default builds. > >>> From the glibc perspective, the major question is how we handle run-time >>> selection of the system call instruction sequence. On i386, we use a >>> function pointer in the TCB to call an instruction sequence in the vDSO. >>> That's problematic from a security perspective. I expect that on >>> POWER9, using a pointer in read-only memory would be equally >>> non-attractive due to a similar lack of PC-relative addressing. We >>> could use the HWCAP bit in the TCB, but that would add another (easy to >>> predict) conditional branch to every system call. >> >> I would have to defer to glibc devs on this. Conditional branch >> should be acceptable I think, scv improves speed as much as several >> mispredicted branches (about 90 cycles). > > But we'd have to pay for that branch (and likely the LR clobber) on > legacy POWER, and that's something to consider, too. We would that's true. > Is there an additional performance hit if a process uses both the old > and new system call sequence? No state or logic required to switch between them or run them concurrently. Just the extra instruction footprint. Thanks, Nick
