[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190814235521.GP9017@brightrain.aerifal.cx>
Date: Wed, 14 Aug 2019 19:55:21 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [RFC] final time64 switch-over patch series
On Fri, Aug 02, 2019 at 05:44:33PM -0400, Rich Felker wrote:
> From 84a4c907b8ea52e11f8edb9ccc1050e31753e5ca Mon Sep 17 00:00:00 2001
> From: Rich Felker <dalias@...ifal.cx>
> Date: Wed, 31 Jul 2019 15:24:58 -0400
> Subject: [PATCH 1/5] add time64 symbol name redirects to public headers, under
> arch control
>
> a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is
> expected to define, to control redirection of symbol names for
> interfaces that involve time_t and derived types. this ensures that
> object files will only be linked to libc interfaces matching the ABI
> whose headers they were compiled against.
>
> along with time32 compat shims, which will be introduced separately,
> the redirection also makes it possible for a single libc (static or
> shared) to be used with object files produced with either the old
> (32-bit time_t) headers or the new ones after 64-bit time_t switchover
> takes place. mixing of such object files (or shared libraries) in the
> same program will also be possible, but must be done with care; ABI
> between libc and a consumer of the libc interfaces is guaranteed to
> match by the the symbol name redirection, but pairwise ABI between
> consumers of libc that define interfaces between each other in terms
> of time_t is not guaranteed to match.
>
> this change adds a dependency on an additional "GNU C" feature to the
> public headers for existing 32-bit archs, which is generally
> undesirable; however, the feature is one which glibc has depended on
> for a long time, and thus which any viable alternative compiler is
> going to need to provide. 64-bit archs are not affected, nor will
> future 32-bit archs be, regardless of whether they are "new" on the
> kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or
> xtensa port). the same applies to newly-added ABIs for existing
> machine-level archs.
> ---
> include/aio.h | 4 ++++
> include/mqueue.h | 5 +++++
> include/poll.h | 6 ++++++
> include/pthread.h | 10 ++++++++++
> include/sched.h | 4 ++++
> include/semaphore.h | 4 ++++
> include/signal.h | 8 ++++++++
> include/sys/resource.h | 4 ++++
> include/sys/select.h | 5 +++++
> include/sys/sem.h | 6 ++++++
> include/sys/socket.h | 6 ++++++
> include/sys/stat.h | 9 +++++++++
> include/sys/time.h | 14 ++++++++++++++
> include/sys/timeb.h | 4 ++++
> include/sys/timerfd.h | 5 +++++
> include/sys/timex.h | 5 +++++
> include/sys/wait.h | 7 +++++++
> include/threads.h | 6 ++++++
> include/time.h | 28 ++++++++++++++++++++++++++++
> include/utime.h | 4 ++++
> 20 files changed, 144 insertions(+)
>
> diff --git a/include/aio.h b/include/aio.h
> index 19bc28a9..482b2a70 100644
> --- a/include/aio.h
> +++ b/include/aio.h
> @@ -62,6 +62,10 @@ int lio_listio(int, struct aiocb *__restrict const *__restrict, int, struct sige
> #define off64_t off_t
> #endif
>
> +#if _REDIR_TIME64
> +int aio_suspend() __asm__("__aio_suspend_time64");
> +#endif
These non-prototype declarations for the redirections are not going to
work, since they're not compatible with C++. So either:
1. We repeat the full declarations with prototype, or
2. We use the GNU C __typeof__ for the redirections, or
3. We eliminate the separate #if _REDIR_TIME64 blocks and instead put
conditionally-defined redirections on the end of the main
declarations.
I kind of lean towards 3, in that it avoids the possibility of
introducing ABI-breaking bugs via inconsistency between the feature
test macro checks at the point of original declaration and the point
of redirection.
I don't like the verbosity and duplication of option 1. I don't like
the GNU C of option 2, but it's probably no worse than the __asm__ we
can't avoid anyway.
In order to do option 3 though we need a place to conditionally define
the macro appropriately. features.h seems natural but it doesn't
necessarily have access to alltypes.h without adding more inclusions
(which impacts compile times on all targets).
It should be possible to do some macro magic to make features.h do a
_T64() function-like macro that expands differently depending on the
definition of _REDIR_TIME64 at the time it's expanded, but this will
require that all archs define it to 0 or 1 rather than leaving it
undefined when not used. Then we can just unconditionally do:
int aio_suspend(const struct aiocb *const [], int, const struct timespec *) _T64(__aio_suspend_time64);
etc.
Does this seem reasonable?
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.
