Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191029230841.GI16318@brightrain.aerifal.cx>
Date: Tue, 29 Oct 2019 19:08:41 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] remaining steps for time64 switchover

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

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.