Re: [PATCH v2] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437)

[Florian Weimer <fweimer@redhat.com>]

* Rich Felker:

> On Fri, Dec 10, 2021 at 04:44:46PM +0100, Florian Weimer via Libc-alpha wrote:
>> * H. J. Lu via Libc-alpha:
>> 
>> > On Fri, Dec 10, 2021 at 3:03 AM Adhemerval Zanella via Libc-alpha
>> > <libc-alpha@sourceware.org> wrote:
>> >>
>> >> Although the kernel ABI uses 64-bit (so it can re-use the syscall
>> >> logic from x86_64), POSIX states the type to be 'long int'.  It
>> >> requires to explicit signal extend the value on syscalls that
>> >> take the value to avoid requiring bumping the minimum kernel version
>> >> (ea2ce8f3514e ("time: Fix get_timespec64() for y2038 safe compat
>> >> interfaces") got merged into v4.18, futex and recvmsg followed in v5.1,
>> >> but v5.6 is considered 'complete').
>> >>
>> >> The fix uses 'long long int' array to represent 'struct timespec',
>> >> since it allows a simpler code than define a kernel specific timespec.
>> >>
>> >> There is no need to compat symbol, the now high-bits are not used
>> >> to represent the nanoseconds and for some syscalls it only issues
>> >> an error (which hardly indicates the need of compat symbol).
>> >>
>> >> Checked on x86_64-linux-gnu-x32 with kernel 4.4.0 and 5.13.
>> >
>> > Isn't it an ABI change for x32?
>> 
>> I agree.  I said so repeatedly.
>
> Can you clarify the sense in which it's an "ABI change"? I don't think
> it's a change at all in the "mechanical" ABI linkage between libc and
> the libc consumer. Of course it is a change in the types at the high
> level language level.

If struct timespec is passed as a register pair, the old type guarantees
that the callee sees a sign-extended value for the nanoseconds in the
register.  With the new type, the upper 32 bits of the register are
either undefined or zero (not sure which).  Existing compiler practice
favors zero extension, I think.  This may cause an observable difference
if only part of the link is upgraded to the new type, which I think
qualifies the change as an ABI break.

> If this were just an enhancement request, I'd be inclined to say just
> drop it, but this is a bug fix for a serious conformance problem
> that's going to have people writing wacky code to work around x32 (if
> anyone even actually cares about x32) and that keeps coming up in
> messy ways like the request to change tv_nsec to snseconds_t. From my
> perspective there is very high value in getting rid of this exception
> to the specification so that stuff doesn't get built around it.

If the kernel view and the userspace view differ, that also causes
practical problems.  Low-level C programmers do not expect a managed
run-time that uses different types, locks around system calls etc., even
though the resulting C implementation is not really POSIX-compliant.

Thanks,
Florian