From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14888 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] remaining steps for time64 switchover Date: Tue, 29 Oct 2019 19:08:41 -0400 Message-ID: <20191029230841.GI16318@brightrain.aerifal.cx> References: <20191021024643.GA6192@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="99945"; 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-14904-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 30 00:08:56 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 1iPabg-000PwF-Qk for gllmg-musl@m.gmane.org; Wed, 30 Oct 2019 00:08:56 +0100 Original-Received: (qmail 19785 invoked by uid 550); 29 Oct 2019 23:08:54 -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 19764 invoked from network); 29 Oct 2019 23:08:54 -0000 Content-Disposition: inline In-Reply-To: <20191021024643.GA6192@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14888 Archived-At: On Sun, Oct 20, 2019 at 10:46:43PM -0400, Rich Felker wrote: > The attached patch series on top of present git master (commit > 9b2921bea1d5017832e1b45d1fd64220047a9802) should contain all changes > needed for fully working time64 on 32-bit archs, in a form that's > plausibly ready for commit (no makeshift hacks just to get things > demonstrably working). The one omission I'm aware of is what to do > with struct utmpx, which is not actually used at present in any libc > interfaces and thus not part of the ABI surface of libc. That will be > addressed in a separate thread. > > Comments and basic testing are welcome at this point. It should be > possible to build for any of the 32-bit archs, but I have only tested > build for a few and only tested execution on i386 and sh. > > Some useful checks for anyone wanting to help test, especially on the > more obscure archs: > > [...] > > - Does software built against new libc headers basically work? strace breaks at build time with static_assert that IPC_STAT==2. This had me momentarily doubting the whole approach of redefining it rather than making __semctl_time64, etc., but it turns out strace also depends on struct semid_ds, shmid_ds, and msqid_ds matching the kernel layouts, which is impossible with time64, so there's really a fundamental problem here. Fortunately, strace already had the right code and just wasn't using it: if HAVE_SYS_SEM_H, etc. aren't defined in config.h (from autoconf), it falls back to using linux/sem.h, etc., which are exactly what it should have been using all along: the kernel struct layouts and command macro definitions. I think the right patch to strace will be simply removing use of libc sysvipc headers (always using the kernel ones); it doesn't seem practical to write a configure test to determine that the libc ones are usable for parsing the kernel struct. So, first "oh no!" averted! But this may be a preview of what's to come. (And I might have chosen strace as an early test case because I expected things like this.) Rich