From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14456 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing glibc from the musl .2 ABI Date: Thu, 25 Jul 2019 16:03:19 -0400 Message-ID: <20190725200319.GN1506@brightrain.aerifal.cx> 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> <20190724212928.GF1506@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="239813"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14472-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 25 22:03:41 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 1hqjxk-0010KD-Ss for gllmg-musl@m.gmane.org; Thu, 25 Jul 2019 22:03:40 +0200 Original-Received: (qmail 13696 invoked by uid 550); 25 Jul 2019 20:03:37 -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 13666 invoked from network); 25 Jul 2019 20:03:36 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14456 Archived-At: On Thu, Jul 25, 2019 at 09:42:23AM -0700, James Y Knight wrote: > On Wed, Jul 24, 2019 at 2:29 PM Rich Felker wrote: > > > On Wed, Jul 24, 2019 at 09:33:05AM -0700, James Y Knight wrote: > > > One thing I've not seen mentioned yet: if this is done, then anyone > > > (whether intentionally or inadvertently) who links any glibc-compiled .o > > or > > > ..a files into a musl binary/shared-lib will be broken. > > > > If it referenced glibc symbols that have been moved out of musl, it > > would just fail to link (at ld time or ldso time, depending on program > > binary/shared lib). The only way it would be silently broken is with > > symbols where glibc and musl share the same symbol name but with > > different ABI (like regexec on 64-bit, which is already possible now, > > or the non-64bit-off_t functions on 32-bit archs, or lots of stuff on > > mips and powerpc where there's minimal or no ABI-compat). > > > > For the time64 stuff, my thought is to try to use redirected-symbol > > names that don't match whatever names glibc will be using, so that > > there's no risk of the link accidentally succeeding. I think it makes > > sense in general to try to have ABI match when we add symbols that > > will also exist in glibc, on the archs that have ABI-compat. > > > > > Up until now, with musl's mostly-glibc-compatible ABI, you could link the > > > two object files together, and generally expect it to work. When > > > compatibility is instead done with magic in the dynamic loader, that > > > obviously can only ever work with a shared-object boundary. > > > > > > I don't know if anyone actually uses musl in a context where this is > > likely > > > to be a problem, but it at least seems worth discussing (and loudly > > > documenting as a warning to users not to do this if implemented). > > > > My thought, for the things where it matters, is that it's an > > improvement to fail. If you really want it to work (e.g. if you have a > > binary-only static library you need to use), you can probably use > > objcopy or similar to remap the symbols to shims. > > > > Does my above analysis sound reasonable to you? > > I had understood from your previous emails that musl would start dropping > glibc-abi-compatibility (potentially in general, not just for the > 64-bit-time transition) of existing "undecorated" functions, and then > restore compatibility only in a shadowed version of that same function name > in libgcompat.so. Unless I misunderstand what you're saying, that's impossible without also dropping musl-ABI compatibility. So no, it wouldn't happen. Rich