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.