From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7011 Path: news.gmane.org!not-for-mail From: Catalin Marinas Newsgroups: gmane.linux.kernel,gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64 Date: Thu, 12 Feb 2015 18:17:35 +0000 Message-ID: <20150212181735.GF25491@e104818-lin.cambridge.arm.com> References: <20141002155217.GH32147@e104818-lin.cambridge.arm.com> <20150210181302.GA23886@brightrain.aerifal.cx> <20150211173919.GF9058@e104818-lin.cambridge.arm.com> <20150211192118.GC23507@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1423765078 16785 80.91.229.3 (12 Feb 2015 18:17:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Feb 2015 18:17:58 +0000 (UTC) Cc: "libc-alpha@sourceware.org" , "pinskia@gmail.com" , "musl@lists.openwall.com" , "linux-kernel@vger.kernel.org" , Andrew Pinski , Marcus Shawcroft , "linux-arm-kernel@lists.infradead.org" To: Rich Felker Original-X-From: linux-kernel-owner@vger.kernel.org Thu Feb 12 19:17:57 2015 Return-path: Envelope-to: glk-linux-kernel-3@plane.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLyKr-00066J-3z for glk-linux-kernel-3@plane.gmane.org; Thu, 12 Feb 2015 19:17:57 +0100 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751609AbbBLSRv (ORCPT ); Thu, 12 Feb 2015 13:17:51 -0500 Original-Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:43473 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbbBLSRu (ORCPT ); Thu, 12 Feb 2015 13:17:50 -0500 Original-Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8]) by foss-mx-na.foss.arm.com (Postfix) with ESMTP id A29D34E4; Thu, 12 Feb 2015 12:17:40 -0600 (CST) Original-Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com [10.112.81.134]) by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 2986A5FAC1; Thu, 12 Feb 2015 12:17:39 -0600 (CST) Original-Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com [10.1.203.148]) by collaborate-mta1.arm.com (Postfix) with ESMTPS id B16A813F8D8; Thu, 12 Feb 2015 12:17:37 -0600 (CST) Content-Disposition: inline In-Reply-To: <20150211192118.GC23507@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Original-Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Xref: news.gmane.org gmane.linux.kernel:1887478 gmane.comp.lib.glibc.alpha:49229 gmane.linux.lib.musl.general:7011 gmane.linux.ports.arm.kernel:393141 Archived-At: On Wed, Feb 11, 2015 at 02:21:18PM -0500, Rich Felker wrote: > On Wed, Feb 11, 2015 at 05:39:19PM +0000, Catalin Marinas wrote: > > On Tue, Feb 10, 2015 at 06:13:02PM +0000, Rich Felker wrote: > > > I don't know if this has been discussed on libc-alpha yet or not, but > > > I think we need to open a discussion of how it relates to open glibc > > > bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64): > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=16437 > > > > I'm trying to understand the problem first. Quoting from the bug above > > (which I guess is quoted form C11): > > > > "The range and precision of times representable in clock_t and time_t > > are implementation-defined. The timespec structure shall contain at > > least the following members, in any order. > > > > time_t tv_sec; // whole seconds -- >= 0 > > long tv_nsec; // nanoseconds -- [0, 999999999]" > > > > So changing time_t to 64-bit is fine on x32. The timespec struct > > exported by the kernel always uses a long for tv_nsec. However, glibc uses > > __syscall_slong_t which ends up as 64-bit for x32 (I guess it mirrors > > the __kernel_long_t definition). > > > > So w.r.t. C11, the exported kernel timespec looks fine. But I think the > > x32 kernel support (and the current ILP32 patches) assume a native > > struct timespec with tv_nsec as 64-bit. > > The exported kernel timespec is not fine if long is defined as a > 32-bit type, which it is for x32 and the proposed aarch64-ILP32 ABIs. The exported kernel headers comply with POSIX as they use long for tv_nsec. The exported headers can be used in user space and with an ILP32 ABI, long is 32-bit. The problem is the syscall handler which uses the same structure in kernel where long is 64-bit. But this doesn't change the fact that the exported header was still correct from a user perspective. The solution (for new ports) could be similar to the other such solutions in the compat layer. A kernel internal structure which is binary-compatible with the ILP32 user one (as exported by the kernel): struct ilp32_timespec_kernel_internal_only { __kernel_time_t tv_sec; /* seconds */ int tv_nsec; /* nanoseconds */ }; and a syscall wrapper which converts between ilp32_timespec and timespec (take compat_sys_clock_settime as an example). If the user structure has some padding (and as I've read in this thread it is allowed), it could be even easier for the kernel. The padding could be 32-bit before or after tv_nsec, depending on endianness. -- Catalin