[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sgxi718r.fsf@oldenburg2.str.redhat.com>
Date: Thu, 24 Jan 2019 12:18:12 +0100
From: Florian Weimer <fweimer@...hat.com>
To: musl@...ts.openwall.com
Subject: Re: Symbol versioning approximation trips on compat symbols
* 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 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).
Thanks,
Florian
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.
