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.