From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13642 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: Wed, 23 Jan 2019 20:43:40 -0500 Message-ID: <20190124014340.GV23599@brightrain.aerifal.cx> References: <87r2d5evvi.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="263578"; 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-13658-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 24 02:43:59 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 1gmU3h-0016QM-SZ for gllmg-musl@m.gmane.org; Thu, 24 Jan 2019 02:43:57 +0100 Original-Received: (qmail 30160 invoked by uid 550); 24 Jan 2019 01:43:53 -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 30139 invoked from network); 24 Jan 2019 01:43:53 -0000 Content-Disposition: inline In-Reply-To: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13642 Archived-At: On Mon, Jan 21, 2019 at 06:57:53PM +0100, Florian Weimer wrote: > On what appears to be current Alpine Linux (musl-1.1.19-r10), the > following reproducer > > ###################################################################### > cat > symver.c < void > compat_function (void) > { > } > __asm__ (".symver compat_function,compat_function@SYMVER"); > > void > call_compat_function (void) > { > return compat_function (); > } > EOF > > echo "SYMVER { };" > symver.map > > cat > main.c < extern void call_compat_function (void); > > int > main (void) > { > call_compat_function (); > } > EOF > > gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c > gcc -Wl,--rpath=. -o main main.c symver.so > ###################################################################### > > fails with: > > $ ./main > Error relocating ./symver.so: compat_function: symbol not found > > The problem is the compatibility symbol (one @ instead of @@). The > dynamic linker is supposed to ignore the difference between the two, the > default vs non-default version only matters to the link editor when > processing an undefined symbol without a symbol version. > > In my case, I do not need symbol interposition and therefore can work > around this, but I wonder if there is some sort of approved compile-time > or link-time check to detect this issue. Unfortunately, the Alpine > Linux toolchain (and part of the system) is built *with* symbol > versioning support, so this does not appear to be straightforward. > > The actual application does not need to make the symbol interposable, so > I can use a hidden alias within the DSO for PLT avoidance (and more > configure checks to disable all this on targets which do not support > *that*). The same issue came up before with libgcc defining and referencing a non-default-version symbol for some weird compatibility hack. I don't remember the details but Szabolcs Nagy was involved in investigating and might. In any case, the root cause is that musl's dynamic linker does not support symbol versioning; for the sake of being able to load libraries that were build with versioning, it always resolves a symbol to the "latest"/default version, the same as ld would do at link time. Normally this is the right thing as long as you don't actually have things that were linked against an old incompatible version, but it also breaks explicit linking to a particular version as in your example above. The right fix is probably to add support for symbol version matching in the dynamic linker. Unfortunately this involves some extra logic in the extreme hot paths, so it's hard to make the cost unobservably low, and last I checked some members of the community were opposed to it on ideological grounds. If there's a good need for it (and I think just avoiding silent breakage of third-party libs using versioning and intending for it to work is a fairly good one already), support can be added, but doing it without negative impact is a pretty big task. Rich