[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190124014340.GV23599@brightrain.aerifal.cx>
Date: Wed, 23 Jan 2019 20:43:40 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Symbol versioning approximation trips on compat symbols
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 <<EOF
> void
> compat_function (void)
> {
> }
> __asm__ (".symver compat_function,compat_function@...VER");
>
> void
> call_compat_function (void)
> {
> return compat_function ();
> }
> EOF
>
> echo "SYMVER { };" > symver.map
>
> cat > main.c <<EOF
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
