From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14441 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing glibc from the musl .2 ABI Date: Wed, 24 Jul 2019 17:17:35 +0200 Message-ID: <20190724151735.GS21055@port70.net> References: <20190717033735.GJ1506@brightrain.aerifal.cx> <2d36174f-ae85-bcd2-1c71-10f50513b1a6@adelielinux.org> <20190717151107.GL1506@brightrain.aerifal.cx> <20190717181651.GN1506@brightrain.aerifal.cx> <20190722155259.GA7445@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="49405"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14457-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 24 17:17:53 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hqJ1d-000Cl0-1f for gllmg-musl@m.gmane.org; Wed, 24 Jul 2019 17:17:53 +0200 Original-Received: (qmail 9857 invoked by uid 550); 24 Jul 2019 15:17:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9812 invoked from network); 24 Jul 2019 15:17:49 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190722155259.GA7445@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14441 Archived-At: * Rich Felker [2019-07-22 11:52:59 -0400]: > So, what I'd (tentatively; for discussion) like to do: > > When ldso loads an application or shared library and detects that it's > glibc-linked (DT_NEEDED for libc.so.6), it both loads a gcompat > library instead *and* flags the dso as needing ABI-compat. The gcompat > library would be permanently RTLD_LOCAL, unable to be used for > resolving global symbols, since it would have to define symbols > conflicting with libc symbols names and with future directions of the > musl ABI. > > Symbol lookups when relocating such a flagged dso would take place by > first processing gcompat (logically, adding it to the head of the dso > search list), then the normal symbol search order. The gcompat library > could also provide a replacement dlsym function, so that dlsym calls > from the glibc-linked DSO also follow this order, and a replacement > dlopen, so that dlopen of libc from the glibc-linked DSO would get the > gcompat module. > > I'm not sure what mechanism gcompat would then use to make its own > references to the underlying real libc functions. This is something > we'd need to think about. i'm not sure how gcompat would implement dlsym, if it's on top of the musl dlsym, then that needs to be accessible already (e.g. by exposing a __musl_dlsym alias) and can be used to do lookups in libc.so. > > Before we decide to do it, please be aware that this would be a bit of > a burden on gcompat to do more than it's doing now. But it would also > make lots of cases work that fundamentally *can't* work now -- compat > with 32-bit code using the legacy 32-bit off_t functions, compat with > 64-bit code using regexec, etc. -- anywhere the musl ABI currently > conflicts with the glibc ABI. Of course much of this is optional. The > new things that would be mandatory would mainly be moving over > existing glibc compat shims (like the __ctype and __xstat stuff) and > implementing converting wrappers where musl's use of reserved space > creates unsafety/incompatibility with the existing glibc code. > > Rich