* Re: [musl] How to support symbol versioning for musl?
2022-03-28 15:37 ` Rich Felker
@ 2022-04-20 7:30 ` up
2022-04-20 8:42 ` Kai Peter
2022-04-25 6:02 ` Yang Zhonghua
2 siblings, 0 replies; 6+ messages in thread
From: up @ 2022-04-20 7:30 UTC (permalink / raw)
To: dalias; +Cc: musl
[-- Attachment #1: Type: text/plain, Size: 5186 bytes --]
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@OLD?
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@libc.org>;
Date: Mon, Mar 28, 2022 11:37 PM
To: "up"<happy2discover@foxmail.com>;
Cc: "musl"<musl@lists.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
[-- Attachment #2: Type: text/html, Size: 5944 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] How to support symbol versioning for musl?
2022-03-28 15:37 ` Rich Felker
2022-04-20 7:30 ` up
@ 2022-04-20 8:42 ` Kai Peter
2022-04-25 6:02 ` Yang Zhonghua
2 siblings, 0 replies; 6+ messages in thread
From: Kai Peter @ 2022-04-20 8:42 UTC (permalink / raw)
To: musl
On 2022-03-28 17:37, Rich Felker wrote:
>
> 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
Thanks for your quick reply. I'm not sure if I understood this
versioning thing overall. However your hint to look in dynlink.c was
very useful. I did some changes to musl's pathes anyway and did set the
sys_path now accordingly to my needs. This is fine for this custom
system. It's working perfect.
Kai
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] How to support symbol versioning for musl?
2022-03-28 15:37 ` Rich Felker
2022-04-20 7:30 ` up
2022-04-20 8:42 ` Kai Peter
@ 2022-04-25 6:02 ` Yang Zhonghua
2022-05-01 16:59 ` Fangrui Song
2 siblings, 1 reply; 6+ messages in thread
From: Yang Zhonghua @ 2022-04-25 6:02 UTC (permalink / raw)
To: musl; +Cc: musl
[-- Attachment #1: Type: text/plain, Size: 3854 bytes --]
Hi guys,
I tried to use the "versym" member of "struct dso", referring to the function "checkver()" of src/internal/vdso.c file.
prerequisites:
defining three versions for one symbol.
questions:
As "dso->strings + dso->syms[i].st_name" of the three symbols was the same name, I tried to use "dso->versym[i]" to distinguish versions. But only the default symbol version was a positive value, the others were both negative values(-32766).
Is there any way to get the right "dso->versym[i]" value for all symbol versions?
Looking forward to your valuable advice. Thank you so much!
Yang Zhonghua
------------------ Original ------------------
From: "musl" <dalias@libc.org>;
Date: Mon, Mar 28, 2022 11:37 PM
To: "up"<happy2discover@foxmail.com>;
Cc: "musl"<musl@lists.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
[-- Attachment #2: Type: text/html, Size: 4498 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] How to support symbol versioning for musl?
2022-04-25 6:02 ` Yang Zhonghua
@ 2022-05-01 16:59 ` Fangrui Song
0 siblings, 0 replies; 6+ messages in thread
From: Fangrui Song @ 2022-05-01 16:59 UTC (permalink / raw)
To: musl
On 2022-04-25, Yang Zhonghua wrote:
>Hi guys,
>
>
>I tried to use the "versym" member of "struct dso", referring to the function "checkver()" of src/internal/vdso.c file.
>
>
>prerequisites:
>defining three versions for one symbol.
>
>
>questions:
>As "dso->strings + dso->syms[i].st_name" of the three symbols was the same name, I tried to use "dso->versym[i]" to distinguish versions. But only the default symbol version was a positive value, the others were both negative values(-32766).
>
>
>Is there any way to get the right "dso->versym[i]" value for all symbol versions?
>Looking forward to your valuable advice. Thank you so much!
>
>
>Yang Zhonghua
You may want to switch posting style
https://www.idallen.com/topposting.html (Top-posting vs Bottom-posting)
to match others.
I have a write-up about glibc rtld behavior (also FreeBSD rtld-elf's) at
https://maskray.me/blog/2020-11-26-all-about-symbol-versioning#rtld-behavior
Paste the most relevant part below:
When searching a definition for `foo`,
* for an object without symbol versioning
+ it can be bound to `foo`
* for an object with symbol versioning
+ it can be bound to `foo` of version `VER_NDX_GLOBAL`. This takes precendence over the next two rules
+ it can be bound to `foo` of any default version
+ it can be bound to `foo` of non-default version index 2 in relocation resolving phase (not dlvsym). The rule retains compatibility when a shared object becomes versioned.
When searching a definition for `foo@v1`,
* for an object without symbol versioning
+ it can be bound to `foo`
* for an object with symbol versioning
+ it can be bound to `foo@v1` or `foo@@v1`
+ it can be bound to `foo` of version `VER_NDX_GLOBAL` in relocation resolving phase (not dlvsym)
^ permalink raw reply [flat|nested] 6+ messages in thread