[musl] [PATCH] fix glibc ABI compat

[musl] [PATCH] fix glibc ABI compat

[Szabolcs Nagy]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

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.

[-- Attachment #2: 0001-fix-glibc-ABI-compat.patch --]
[-- Type: text/x-diff, Size: 2906 bytes --]

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

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

Re: [musl] [PATCH] fix glibc ABI compat

[Rich Felker]

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