From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 25097 invoked from network); 28 Mar 2020 15:45:50 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 28 Mar 2020 15:45:50 -0000 Received: (qmail 7461 invoked by uid 550); 28 Mar 2020 15:45:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7437 invoked from network); 28 Mar 2020 15:45:46 -0000 Date: Sat, 28 Mar 2020 11:45:33 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200328154533.GK11469@brightrain.aerifal.cx> References: <20200328141600.GU14278@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200328141600.GU14278@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] fix glibc ABI compat 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 > 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