From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 89BB33858D39 for ; Sat, 11 Dec 2021 18:50:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 89BB33858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-315-Q3RhxGRMNkOHsRpMEx1uZg-1; Sat, 11 Dec 2021 13:50:11 -0500 X-MC-Unique: Q3RhxGRMNkOHsRpMEx1uZg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 038D22F25; Sat, 11 Dec 2021 18:50:10 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.17.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 296305E27A; Sat, 11 Dec 2021 18:50:08 +0000 (UTC) From: Florian Weimer To: Rich Felker Cc: "H.J. Lu via Libc-alpha" Subject: Re: [PATCH v2] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437) References: <20211210110233.1401640-1-adhemerval.zanella@linaro.org> <87mtl879ch.fsf@oldenburg.str.redhat.com> <20211211000844.GB7074@brightrain.aerifal.cx> Date: Sat, 11 Dec 2021 19:50:06 +0100 In-Reply-To: <20211211000844.GB7074@brightrain.aerifal.cx> (Rich Felker's message of "Fri, 10 Dec 2021 19:08:45 -0500") Message-ID: <87bl1n2cyp.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 18:50:14 -0000 * 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 >> > 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