From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14558 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: time64 abi choices for glibc and musl Date: Mon, 12 Aug 2019 14:20:52 -0400 Message-ID: <20190812182052.GV9017@brightrain.aerifal.cx> References: <20190810175808.GA13205@brightrain.aerifal.cx> <20190811021818.GM9017@brightrain.aerifal.cx> <20190812015514.GO9017@brightrain.aerifal.cx> <20190812180119.GU9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="241974"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14574-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 12 20:21:07 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hxEwN-0010qR-2Z for gllmg-musl@m.gmane.org; Mon, 12 Aug 2019 20:21:07 +0200 Original-Received: (qmail 11637 invoked by uid 550); 12 Aug 2019 18:21:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11617 invoked from network); 12 Aug 2019 18:21:04 -0000 Content-Disposition: inline In-Reply-To: <20190812180119.GU9017@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14558 Archived-At: 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