[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Aug 2019 14:20:52 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: time64 abi choices for glibc and musl
Taking this off CC, just to musl list...
On Mon, Aug 12, 2019 at 02:01:19PM -0400, Rich Felker wrote:
> On Sun, Aug 11, 2019 at 09:55:14PM -0400, Rich Felker wrote:
> > On Sun, Aug 11, 2019 at 05:31:48PM -0700, Paul Eggert wrote:
> > > Rich Felker wrote:
> > > >this is a best-effort
> > > >thing anyway, and can't inherently be expected to work, but the choice
> > > >that makes things easy on the libc implementation side is *also* the
> > > >choice that makes this work best.
> > >
> > > It doesn't entirely simplify libc, as it enlarges struct stat and
> > > (more importantly) makes struct stat tricky. This is a judgment
> > > call, but I would say we're better off in the long run with a
> > > simpler struct stat that ordinary programmers will understand
> > > easily, even if this complicates nftw implementation during the
> > > transition.
> >
> > The various archs already have random junk padding in struct stat.
>
> Apologies; I was under a longstanding mistaken impression that glibc
> used the kernel stat64 types, and had per-arch bits headers to provide
> them, but apparently it doesn't and always uses its own fixed, fairly
> clean layout (sadly without reserved space for expansion), though.
>
> So indeed it would be a little bit of an uglification to add
> time64-on-32-bit-arch members here. I still think the benefits to
> minimizing breakage of applications (and avoiding the need for
> duplicate [n]ftw implementations and symbol redirects, which nobody
> has proposed doing yet, likely because nobody even realized they would
> have been needed) are worth it, but my assessment was wrong.
>
> This also means whatever glibc decides to do about struct stat is
> irrelevant to musl's glibc-ABI-compat goals; what I assumed was
> working now is in fact broken, but doesn't matter because the __xstat
> shims can fix it up if desired.
I'm quite surprised this happened, and it's certainly causing some
(likely high) degree of breakage for any attempts to use
glibc-ABI-compat/gcompat stuff. i386 is not affected, precisely
because glibc's unified type is just a copy of the i386 version of the
kernel's struct stat64; them being the same is probably how I wrongly
assumed glibc used the kernel types, back when musl was i386-only. I
vaguely remember some discussion of whether musl should translate stat
back then, so it might have been known but the importance
overlooked...
In any case, this should be fixed. Fortunately for us, the libc stat
functions are never callable from glibc code, because glibc redirects
them through the __xstat functions in libc_nonshared.a. Since glibc
has a unified type for all archs, it would be easy to add code to
convert to the glibc type here, either in musl or gcompat.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
