mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Rich Felker <dalias@libc.org>
Cc: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	"pinskia@gmail.com" <pinskia@gmail.com>,
	"musl@lists.openwall.com" <musl@lists.openwall.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Pinski <apinski@cavium.com>,
	Marcus Shawcroft <Marcus.Shawcroft@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64
Date: Thu, 12 Feb 2015 18:17:35 +0000	[thread overview]
Message-ID: <20150212181735.GF25491@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <20150211192118.GC23507@brightrain.aerifal.cx>

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

  reply	other threads:[~2015-02-12 18:17 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20141002155217.GH32147@e104818-lin.cambridge.arm.com>
2015-02-10 18:13 ` Rich Felker
2015-02-11 17:39   ` Catalin Marinas
2015-02-11 19:05     ` Szabolcs Nagy
2015-02-11 19:22       ` [musl] " H.J. Lu
2015-02-11 19:50       ` arnd
2015-02-11 20:12         ` Rich Felker
2015-02-11 20:47           ` Jens Gustedt
2015-02-11 21:02           ` arnd
2015-02-11 21:09             ` arnd
2015-02-11 21:37             ` [musl] " Rich Felker
2015-02-16 17:20               ` Arnd Bergmann
2015-02-16 17:51                 ` [musl] " Rich Felker
2015-02-16 19:38                   ` Arnd Bergmann
2015-02-12  8:12       ` Szabolcs Nagy
2015-02-12 17:07         ` Catalin Marinas
2015-02-11 19:21     ` Rich Felker
2015-02-12 18:17       ` Catalin Marinas [this message]
2015-02-12 18:59         ` arnd
2015-02-13 13:33           ` Catalin Marinas
2015-02-13 16:30             ` Rich Felker
2015-02-13 17:33               ` Catalin Marinas
2015-02-13 18:37                 ` Rich Felker
2015-02-16 14:40                   ` Arnd Bergmann
2015-02-16 15:38                     ` Rich Felker
2015-02-16 16:54                       ` Arnd Bergmann
2015-02-11 18:33   ` H.J. Lu
2015-02-11 19:02     ` Rich Felker
2015-02-11 19:16       ` H.J. Lu
2015-02-11 19:25         ` Rich Felker
2015-02-11 19:34           ` H.J. Lu
2015-02-11 19:47             ` Rich Felker
2015-02-11 19:57               ` H.J. Lu
2015-02-11 20:15                 ` Andy Lutomirski
2015-02-12 15:50                   ` Catalin Marinas
2015-02-12 16:13                     ` Rich Felker
2015-02-12 16:30                     ` H.J. Lu
2015-02-12 17:00                       ` Rich Felker
2015-02-11 21:41       ` Joseph Myers
2015-02-11 19:04     ` Josiah Worcester

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150212181735.GF25491@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=apinski@cavium.com \
    --cc=dalias@libc.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=musl@lists.openwall.com \
    --cc=pinskia@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).