[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220328153707.GE7074@brightrain.aerifal.cx>
Date: Mon, 28 Mar 2022 11:37:08 -0400
From: Rich Felker <dalias@...c.org>
To: up <happy2discover@...mail.com>
Cc: musl <musl@...ts.openwall.com>
Subject: Re: How to support symbol versioning for musl?
On Mon, Mar 28, 2022 at 05:44:00PM +0800, up wrote:
> Hi guys,
>
>
> I've discussed this topic online(https://web.libera.chat).
> I got the conclusion that musl does not support symbol versioning(or
> musl supports only one symbol version, see at
> https://wiki.musl-libc.org/functional-differences-from-glibc.html#Symbol-versioning).
>
>
> Here is my plan,
> 1. find out how musl is compatiable with glibc symbol versioning.
> 2. modify musl dynamic linker to support more than two symbol versions.
>
>
> But I get stuck in finding out the mechanism of dynamic linker.
> Where should I start and how to procceed?
>
>
> Hope you guys could give me some advice. Thank you so much!
This is a topic that's come up before. Symbol versioning was
intentionally not implemented to begin with because it's a really bad
tool for what it's intended for and we intended not to use it in musl
itself, but indeed still some things want to use it on their own, and
at one point there was some wacky use of symbol versioning in
libgcc_s.so that looked like it was going to be a problem to handle
without supporting symbol versioning. So there has been talk on and
off about supporting it in the future, but I think it's still a topic
members of the community disagree over.
Implementation-wise, supporting versioning requires adding the logic
to symbol lookups. Right now they use the versym table only to
determine if the candidate symbol is default-version (that would be
used by ld), in order not to break linking with libraries that were
built with versioning. They don't have access to the version requested
by the reference to the symbol. So additional information would have
to be passed into the inner lookup loops, where it likely does have
nontrivial costs for symbol lookup performance.
Lines 244-330 of ldso/dynlink.c are the relevant location where this
would take place. Making it efficient might also require setting up
some additional data in advance; I'm not sure. It's been a long time
since I looked at what it might take to do this.
If actual symbol versioning isn't a hard requirement for what you're
doing, you might look at alternate ways of achieving what you want.
The core flaw of symbol versioning is that versions are bound at
link-time, but the actual version needed comes from what headers the
consumer of the library was built with at compile-time. A much simpler
and more-correct version of symbol versioning can therefore be
achieved just by using the preprocessor to remap identifiers in the
library's headers:
#define libfoo_funcbar libfoo_funcbar_v2
...
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.
