From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13645 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Symbol versioning approximation trips on compat symbols Date: Thu, 24 Jan 2019 12:09:32 +0100 Message-ID: <20190124110931.GU21289@port70.net> References: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> <20190124014340.GV23599@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="174264"; 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-13661-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 24 12:09:47 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 1gmctH-000jFk-O0 for gllmg-musl@m.gmane.org; Thu, 24 Jan 2019 12:09:47 +0100 Original-Received: (qmail 27997 invoked by uid 550); 24 Jan 2019 11:09:45 -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 27979 invoked from network); 24 Jan 2019 11:09:44 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190124014340.GV23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13645 Archived-At: * Rich Felker [2019-01-23 20:43:40 -0500]: > 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 libgcc_s.so.1 issue on x86 was an extern object symbol (used by function-multi-versioning ifuncs) that is initialized by a ctor. 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. so musl cannot load libgcc_s.so.1 since there is no default version (@@) of the symbol. (in a musl based gcc this is fixed: there is no ifunc support or compat issue anyway https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01125.html you would expect that it's enough to build gcc for --disable-gnu-indirect-function or --disable-symvers but even with those the compat symbol is there...) i wonder what is the use-case for using a compat symbol without introducing a new default version for the symbol in general? > > 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