From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6984 Path: news.gmane.org!not-for-mail From: Josiah Worcester Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lib.glibc.alpha,gmane.linux.ports.arm.kernel,gmane.linux.kernel Subject: Re: Re: [PATCHv3 00/24] ILP32 support in ARM64 Date: Wed, 11 Feb 2015 13:04:19 -0600 Message-ID: References: <20141002155217.GH32147@e104818-lin.cambridge.arm.com> <20150210181302.GA23886@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11409164aab2e8050ed4abc3 X-Trace: ger.gmane.org 1423681487 20363 80.91.229.3 (11 Feb 2015 19:04:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2015 19:04:47 +0000 (UTC) Cc: GNU C Library , Andrew Pinski , Rich Felker , linux-arm-kernel@lists.infradead.org, LKML , Andrew Pinski , Catalin Marinas To: musl@lists.openwall.com Original-X-From: musl-return-6997-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 11 20:04:40 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YLcaW-0004f0-1r for gllmg-musl@m.gmane.org; Wed, 11 Feb 2015 20:04:40 +0100 Original-Received: (qmail 30168 invoked by uid 550); 11 Feb 2015 19:04:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30097 invoked from network); 11 Feb 2015 19:04:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QCvM3iV/YBXizEH/4dGp6AvNqzHgl7i6T6G86w9A7ss=; b=n8g+CUUn2q3fVIQ/kyMb8ReK8hZih46gZUFQCwapUYWudEZkdmWAPVCWA69jbRDiq8 Ht3QAkFzzwa6K4KQflhX+ZrNamrf461nD4WcnK++7nB/QxWI3zbP/eclaaTb96RyiEF5 Cb6ElIQ1YpJFuVvl9vO0utcA3n0kHhFD2c4AbUKGCyK5PWNZF0f4FO525DCzFj7KyeCv mhX5sDTwdfh5L1CmRAwGF2OSilyMY0axjftDj2MzxD022+d0hTjmgVWVhioJ2WikptRQ NEdQbsnwoBlLpQiIjHp9/4UQd5lx2xDciPB5bamVqZzX6ybJeBTvVYxBuHpuAtIIWmE3 VvEg== X-Received: by 10.202.232.65 with SMTP id f62mr27312oih.116.1423681459498; Wed, 11 Feb 2015 11:04:19 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:6984 gmane.comp.lib.glibc.alpha:49150 gmane.linux.ports.arm.kernel:392799 gmane.linux.kernel:1886697 Archived-At: --001a11409164aab2e8050ed4abc3 Content-Type: text/plain; charset=UTF-8 On Feb 11, 2015 12:59 PM, "H.J. Lu" wrote: > > On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker wrote: > > On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote: > >> On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote: > >> > New version with all of the requested changes. Updated to the > >> > latest sources. > >> > > >> > Notable changes from the previous versions: > >> > VDSO code has been factored out to be easier to understand and > >> > easier to maintain. > >> > Move the config option to the last thing that gets added. > >> > Added some extra COMPAT_* macros for core dumping for easier usage. > >> > >> Apart from a few comments I've made, I would also like to see non-empty > >> commit logs and long line wrapping (both in commit logs and > >> Documentation/). Otherwise, the patches look fine. > >> > >> So what are the next steps? Are the glibc folk ok with the ILP32 Linux > >> ABI? On the kernel side, what I would like to see: > > > > 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 > > Please leave x32 out of this discussion. I have resolved this bug > as WONTFIX. > > > While most of the other type changes proposed (I'm looking at > > https://lkml.org/lkml/2014/9/3/719) are permissible and simply > > ugly/undesirable, defining struct timespec with tv_nsec having any > > type other than long conflicts with the requirements of C11 and POSIX, > > and WG14 is unlikely to be interested in changing the C language > > because the Linux kernel has the wrong type in timespec. > > > > Note that on aarch64 ILP32, the consequences of not fixing this right > > away will be much worse than on x32, since aarch64 (at least as I > > understand it) supports big endian where it's not just a matter of > > sign-extending the value from userspace and ignoring the padding, but > > rather changing the offset of the tv_nsec member. > > > > Working around the discrepencies in userspace IS possible, but ugly. > > We do it in musl libc for x32 right now -- see: > > > > http://git.musl-libc.org/cgit/musl/tree/arch/x32/syscall_arch.h?id=v1.1.6 > > http://git.musl-libc.org/cgit/musl/tree/arch/x32/src/syscall_cp_fixup.c?id=v1.1.6 > > You are free to do what you feel appropriate. I have no plans > to change x32 on this in glibc at this moment. Would you be so kind as to document your intentional nonconformance with C and POSIX in the glibc manual, perhaps also the readme and website? Something like "for the sake of simplicity, some ports do not provide a correct C environment. Any such failures should not be considered bugs."? --001a11409164aab2e8050ed4abc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Feb 11, 2015 12:59 PM, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>
> On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker <dalias@libc.org> wrote:
> > On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
> >> On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote= :
> >> > New version with all of the requested changes.=C2=A0 Upd= ated to the
> >> > latest sources.
> >> >
> >> > Notable changes from the previous versions:
> >> > VDSO code has been factored out to be easier to understa= nd and
> >> > easier to maintain.
> >> > Move the config option to the last thing that gets added= .
> >> > Added some extra COMPAT_* macros for core dumping for ea= sier usage.
> >>
> >> Apart from a few comments I've made, I would also like to= see non-empty
> >> commit logs and long line wrapping (both in commit logs and > >> Documentation/). Otherwise, the patches look fine.
> >>
> >> So what are the next steps? Are the glibc folk ok with the IL= P32 Linux
> >> ABI? On the kernel side, what I would like to see:
> >
> > 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 gl= ibc
> > bug #16437, which presently applies only to x32 (ILP32 ABI on x86= _64):
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=3D16437
>
> Please leave x32 out of this discussion.=C2=A0 I have resolved this bu= g
> as WONTFIX.
>
> > While most of the other type changes proposed (I'm looking at=
> > https://lkml.org/l= kml/2014/9/3/719) are permissible and simply
> > ugly/undesirable, defining struct timespec with tv_nsec having an= y
> > type other than long conflicts with the requirements of C11 and P= OSIX,
> > and WG14 is unlikely to be interested in changing the C language<= br> > > because the Linux kernel has the wrong type in timespec.
> >
> > Note that on aarch64 ILP32, the consequences of not fixing this r= ight
> > away will be much worse than on x32, since aarch64 (at least as I=
> > understand it) supports big endian where it's not just a matt= er of
> > sign-extending the value from userspace and ignoring the padding,= but
> > rather changing the offset of the tv_nsec member.
> >
> > Working around the discrepencies in userspace IS possible, but ug= ly.
> > We do it in musl libc for x32 right now -- see:
> >
> > http://git.musl-libc.org/cgit/musl/tree/arch/x32/sys= call_arch.h?id=3Dv1.1.6
> > http://git.musl-libc.org/cgit/musl/tree/arch= /x32/src/syscall_cp_fixup.c?id=3Dv1.1.6
>
> You are free to do what you feel appropriate.=C2=A0 I have no plans > to change x32 on this in glibc at this moment.

Would you be so kind as to document your intentional nonconf= ormance with C and POSIX in the glibc manual, perhaps also the readme and w= ebsite?

Something like "for the sake of simplicity, some ports = do not provide a correct C environment. Any such failures should not be con= sidered bugs."?

--001a11409164aab2e8050ed4abc3--