From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13655 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Symbol versioning approximation trips on compat symbols Date: Sat, 26 Jan 2019 23:04:24 -0500 Message-ID: <20190127040424.GA23599@brightrain.aerifal.cx> References: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> <20190124014340.GV23599@brightrain.aerifal.cx> <20190124110931.GU21289@port70.net> <87sgxi718r.fsf@oldenburg2.str.redhat.com> 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="103756"; 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-13671-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 27 05:04: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 1gnbgV-000QpR-TU for gllmg-musl@m.gmane.org; Sun, 27 Jan 2019 05:04:39 +0100 Original-Received: (qmail 23594 invoked by uid 550); 27 Jan 2019 04:04: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 23574 invoked from network); 27 Jan 2019 04:04:36 -0000 Content-Disposition: inline In-Reply-To: <87sgxi718r.fsf@oldenburg2.str.redhat.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13655 Archived-At: On Thu, Jan 24, 2019 at 12:18:12PM +0100, Florian Weimer wrote: > * Szabolcs Nagy: > > > but it turned out to be broken (ifunc resolvers may run before > > relocations for the extern object are processed), so the symbol > > was removed (moved to libgcc.a), but a compat symbol (@) was > > kept around and the ctor of libgcc_s.so.1 still references it. > > I assume we cannot use a hidden alias to eliminate the symbolic > reference because it is a data symbol, so copy relocations are a > possibility and with the hidden alias, the constructor would update the > wrong object? I believe we had a perfectly workable alternate solution using something like that, but someone on the upstream side wasn't willing to change it. > > i wonder what is the use-case for using a compat symbol without > > introducing a new default version for the symbol in general? > > A compat symbol can be implemented by a different library, and > applications can link to the symbol and get it from the new library. > > Mostly it is just for documenting intent, marking the symbol as > deprecated. It's still relatively easy to link to the symbol from new > binaries (even without resorting to dlvsym). For what it's worth, compat symbols would have let us remove symbols that shouldn't have been put in musl, such as lchmod (which confuses broken apps which wrongly expect that, if it exists, it should work) and perhaps all the LFS64 symbols (which should be present for binary-compat but not at ld-time so that configure doesn't detect and try to use them). However, doing it that way would put a symver table in musl libc.so, resulting in lots of other behaviors we almost surely don't want. It does shed some light on possible motivations, though, I think. Rich