[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tencent_3FF8046109B9B54CCEC448F696A035FF7B0A@qq.com>
Date: Wed, 20 Apr 2022 15:30:17 +0800
From: "up" <happy2discover@...mail.com>
To: "dalias" <dalias@...c.org>
Cc: "musl" <musl@...ts.openwall.com>
Subject: Re: How to support symbol versioning for musl?
Hi Rich,
Sorry to trouble you again about symbol versioning(regardless of rationality).
I've investigated the relevant code of dynamic linker and done some experiments, which raises the following questions,
prerequisites:
1. clone the repo https://github.com/rofl0r/symbol-versioning-test
2. use the musl-gcc wrapper to compile the code
questions:
1. I tried the command "readelf -sD libdso.so", which output two identical symbol "func" in the symbol table of ".gnu.hash".
Symbol table of `.gnu.hash' for image:
Num Buc: Value Size Type Bind Vis Ndx Name
5 0: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS NEW
6 2: 0000000000001110 23 FUNC GLOBAL DEFAULT 12 func
7 2: 00000000000010f9 23 FUNC GLOBAL DEFAULT 12 func
8 2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS OLD
the function gnu_lookup() of ldso/dynlink.c, uses the hashtab to find a symbol. It returns the first "func"(0000000000001110) that is the default symbol. Should I change the hashtab for saving complete symbol name? like func@@NEW and func@...?
2. I couldn't tell the meaning of "versym" in "struct dso". When "dso->versym[i] > 0", its value is 3, not NEW or OLD. Neither is "dso->strings + dso->versym[i]".
3. It seems like that the function map_library() doesn't save information of the ".dynsym" table. I think I need to change the behavior to save all symbol versions, right?
Looking forward to your valuable advice. Thank you so much!
------------------ Original ------------------
From: "musl" <dalias@...c.org>;
Date: Mon, Mar 28, 2022 11:37 PM
To: "up"<happy2discover@...mail.com>;
Cc: "musl"<musl@...ts.openwall.com>;
Subject: Re: [musl] 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
Content of type "text/html" skipped
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.
