From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14291 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Revisiting 64-bit time_t Date: Sat, 29 Jun 2019 12:35:01 -0400 Message-ID: <20190629163501.GK1506@brightrain.aerifal.cx> References: <20190628150659.GD1506@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="18441"; 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-14307-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 29 18:35:16 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 1hhGJo-0004iD-JE for gllmg-musl@m.gmane.org; Sat, 29 Jun 2019 18:35:16 +0200 Original-Received: (qmail 21948 invoked by uid 550); 29 Jun 2019 16:35:14 -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 21929 invoked from network); 29 Jun 2019 16:35:13 -0000 Content-Disposition: inline In-Reply-To: <20190628150659.GD1506@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14291 Archived-At: On Fri, Jun 28, 2019 at 11:06:59AM -0400, Rich Felker wrote: > [...] > So I'm thinking more and more about doing a different fix. In a way > it's like how glibc did 64-bit off_t, and how they're doing 64-bit > time_t, except it wouldn't be switchable and wouldn't default to the > old behavior; once we pull the lever, everything would be built with > 64-bit time_t. This would work via symbol redirction in the headers > for the affected functions (probably via a bits header for the 32-bit > archs), which is valid because, by virtue of using time_t or a derived > type, the standard requires that you include the headers to get the > declaration rather than declaring the function yourself. > > Doing it this way does not break application-to-libc ABI, because the > old symbols still exist; they're just not used for linking new > programs. It does however impact ABI between libraries outside libc if > they use time_t or any of the derived types (timespec, stat, ...) in > their public (not internal, only public) APIs. How big that impact > would be is an open question; it might mean this approach would > require some coordinated updating of affected libraries and > applications using them in sync to prevent breakage. > > Aside from community feedback, what's needed to make this possible, if > it's going to happen, is some good analysis of the scope of breakage. > Such analysis would also benefit glibc -- it would help determine how > safe their _TIME_BITS=64 option will be and whether it can be turned > on safely by default in the presence of old libraries built without > it. I've already discussed this casually with a few people and it > looks like the right starting point would be getting a Debian system > (Debian because their repo is utterly huge) with ALL library packages > installed and grepping /usr/include for all headers that involve > time_t or any of the derived types. Then, manual analysis would need > to be done to determine whether the usage actually has an impact. > > If there are a significant number of affected libraries and we want to > go forward with something like this anyway, there should probably be > an optional patch distros can use to make ldso refuse to load certain > tagged .so files into a process where any of the 64-bit time symbols > have been referenced. This would ensure transitioning users get an > error message rather than silent misexecution. A couple observations: 1. dlsym is problematic. You can't have a correct implementation where dlsym("time") returns the old (now-signature-mismatched) time symbol rather than the redirected one. I think this just necessitates having affected archs also redirect the dlsym symbol, to call a patch-up wrapper. Moderately ugly, but not a show-stopper. 2. The glibc ABI-compat __statx stuff. I'm not sure if glibc is using these for its time64 versions of the interfaces, or if it finally abandoned that broken framework (that beaks both dlsym and function pointer equality). If they're still using it and we want to maintain support for ABI-compat, we need to update these to handle the time64 versions too. Rich