mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] fix glibc ABI compat
Date: Sat, 28 Mar 2020 11:45:33 -0400	[thread overview]
Message-ID: <20200328154533.GK11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200328141600.GU14278@port70.net>

On Sat, Mar 28, 2020 at 03:16:01PM +0100, Szabolcs Nagy wrote:
> i recently run into a missing glibc abi compat symbol
> when trying to run a glibc linked executable with musl.
> 
> __strftime_l is at least used by glibc linked libstdc++
> but glibc linked libstdc++ can have compatibility issues
> with musl so it's not clear how commonly it is useful.
> 
> likewise i don't know how likely the glibc libresolv
> symbols may be useful to have in musl.
> 
> but it does not seem to hurt to have these exported.

> >From 6e8e7105d210f195caf93422f6b9d880e7cc0cc0 Mon Sep 17 00:00:00 2001
> From: Szabolcs Nagy <nsz@port70.net>
> Date: Sat, 28 Mar 2020 11:11:32 +0000
> Subject: [PATCH] fix glibc ABI compat
> 
> commit 0676c3a34c7bf12b33f8f5efb92476f4ffc7f20e made various
> internal symbols hidden, but some of those symbols are useful
> for glibc ABI compatibility (e.g. __nl_langinfo_l is internal
> but was not made hidden).
> 
> following symbols are hidden in musl, but exported in glibc:
> 
> __clock_gettime
> __clone
> __dn_expand
> __getauxval
> __gmtime_r
> __lseek
> __madvise
> __mmap
> __mprotect
> __munmap
> __pthread_key_create
> __pthread_mutex_lock
> __pthread_mutex_trylock
> __pthread_mutex_unlock
> __pthread_once
> __pthread_rwlock_rdlock
> __pthread_rwlock_tryrdlock
> __pthread_rwlock_trywrlock
> __pthread_rwlock_unlock
> __pthread_rwlock_wrlock
> __res_mkquery
> __res_send
> __sigaction
> __stpcpy
> __stpncpy
> __strftime_l
> __wait

Note that not all of these are the same as or even related to the
glibc symbols by the same name. For example __wait is a futex wait,
not a namespace-hidden version of the wait function that waits for
exited child processes. And __clone is a raw clone syscall, not
suitable to provide the public clone function (doesn't match variadic
signature, doesn't use errno).

> at least the following symbols appear in glibc installed headers
> currently so binaries can plausably end up using them:
> 
> __dn_expand
> __res_mkquery
> __res_send
> __stpcpy
> __stpncpy
> 
> and it is known that glibc linked libstdc++ uses
> 
> __strftime_l
> 
> it seems there never was a redirection to __stpcpy or __stpncpy
> in glibc headers and there is no known direct usage of them so
> they are kept hidden in musl.
> ---
>  src/include/resolv.h | 6 +++---
>  src/include/time.h   | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/include/resolv.h b/src/include/resolv.h
> index 945e89e6..6387adca 100644
> --- a/src/include/resolv.h
> +++ b/src/include/resolv.h
> @@ -3,10 +3,10 @@
>  
>  #include "../../include/resolv.h"
>  
> -hidden int __dn_expand(const unsigned char *, const unsigned char *, const unsigned char *, char *, int);
> +int __dn_expand(const unsigned char *, const unsigned char *, const unsigned char *, char *, int);
>  
> -hidden int __res_mkquery(int, const char *, int, int, const unsigned char *, int, const unsigned char*, unsigned char *, int);
> -hidden int __res_send(const unsigned char *, int, unsigned char *, int);
> +int __res_mkquery(int, const char *, int, int, const unsigned char *, int, const unsigned char*, unsigned char *, int);
> +int __res_send(const unsigned char *, int, unsigned char *, int);
>  hidden int __res_msend(int, const unsigned char *const *, const int *, unsigned char *const *, int *, int);
>  
>  #endif
> diff --git a/src/include/time.h b/src/include/time.h
> index cbabde47..4f94bc39 100644
> --- a/src/include/time.h
> +++ b/src/include/time.h
> @@ -10,6 +10,6 @@ hidden char *__asctime_r(const struct tm *, char *);
>  hidden struct tm *__gmtime_r(const time_t *restrict, struct tm *restrict);
>  hidden struct tm *__localtime_r(const time_t *restrict, struct tm *restrict);
>  
> -hidden size_t __strftime_l(char *restrict, size_t, const char *restrict, const struct tm *restrict, locale_t);
> +size_t __strftime_l(char *restrict, size_t, const char *restrict, const struct tm *restrict, locale_t);
>  
>  #endif
> -- 
> 2.24.1

Since we're still planning in the near future to move glibc ABI-compat
out of musl proper, I think I'd rather not re-expose the symbols that
we haven't had any reports of programs missing (the resolver ones).
There's a large portion of the glibc resolver API that we don't even
implement. Indeed it looks like glibc's headers redirect *all* of the
functions in resolv.h to the __-prefixed versions of them, but we
don't even have __-prefixed versions of most, so I don't see how
adding just a few of them makes sense.

__strftime_t does seem to be a real-world regression that should be
fixed until we're ready to move ABI-compat elsewhere, though.

Rich

      reply	other threads:[~2020-03-28 15:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-28 14:16 Szabolcs Nagy
2020-03-28 15:45 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200328154533.GK11469@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).