Hi,
I came across a library `libexiv2.so'(www.exiv2.org) which has some hidden symbols in it. But the `Version symbol' entries for those hidden symbols are shown as - 1 *global* - by `eu-readelf -sV'. Now if symbol is hidden
- shouldn't the highest(15'th) bit of the corresponding `Version symbol' entry be set? And if so, then it could not possibly equate to 1, right?
The other thing I wanted to confirm was,
- a binary(say tcpdump) is linked to a library(libpcap) which does not use Symbol Versioning and does not have `Version definition' section in it. In such a case,
$ `eu-readelf -sV tcpdump'
shows an output wherein, `Version symbol' entries for symbols defined in libpacp are shown as: 0 *local* . Which means the symbol is defined in the same object and is not accessible outside of the same, right?
So could I infer that
- `Version symbol' entries are greater than 1 if and only if the concerned library(or DSO) uses symbol versioning.
- And if so, there is no way of knowing if a *local* symbol is defined in the same object/binary or is resolved from a library while running?
Thank you. -- Regards - Prasad
Uli is the real expert here, so I may be a little off.
I came across a library `libexiv2.so'(www.exiv2.org) which has some hidden symbols in it. But the `Version symbol' entries for those hidden symbols are shown as - 1 *global* - by `eu-readelf -sV'. Now if symbol is hidden
- shouldn't the highest(15'th) bit of the corresponding `Version symbol' entry be set? And if so, then it could not possibly equate to 1, right?
I don't know that ST_VISIBILITY bits relate to version sets in this way.
a binary(say tcpdump) is linked to a library(libpcap) which does not use Symbol Versioning and does not have `Version definition' section in it. In such a case,
$ `eu-readelf -sV tcpdump'
shows an output wherein, `Version symbol' entries for symbols defined in libpacp are shown as: 0 *local* . Which means the symbol is defined in the same object and is not accessible outside of the same, right?
No. These are undefined symbols in tcpdump. The 0 indicates lack of a version binding for the symbol.
- `Version symbol' entries are greater than 1 if and only if the concerned library(or DSO) uses symbol versioning.
I think this is correct.
- And if so, there is no way of knowing if a *local* symbol is defined in the same object/binary or is resolved from a library while running?
SHN_UNDEF symbols always have to be resolved.
Hello Roland, thanks so much for the reply.
On Tue, 28 Apr 2009, Roland McGrath wrote:
- And if so, there is no way of knowing if a *local* symbol is defined in the same object/binary or is resolved from a library while running?
SHN_UNDEF symbols always have to be resolved.
Yes true, but a given UNDEF symbol can resolve from *any* of the libraries(DSOs) to which the binary is linked to, right? Or could we predict that for sure?
Thank you. -- Regards - Prasad
Yes true, but a given UNDEF symbol can resolve from *any* of the libraries(DSOs) to which the binary is linked to, right? Or could we predict that for sure?
If the SHN_UNDEF symbol has symbol version info, that constrains what defining symbols can satisfy that reference. If not (0/1), then any symbol(?) will match--or maybe it's any unversioned/base-version symbol?
On 04/28/2009 08:02 AM, P J P wrote:
I came across a library `libexiv2.so'(www.exiv2.org) which has some hidden symbols in it. But the `Version symbol' entries for those hidden symbols are shown as - 1 *global* - by `eu-readelf -sV'. Now if symbol is hidden
- shouldn't the highest(15'th) bit of the corresponding `Version symbol'
entry be set? And if so, then it could not possibly equate to 1, right?
Symbol visibility has not really anything to do with versioning.
But hidden symbols shouldn't be in the dynamic symbol table and only symbols in the dynamic symbol table have version symbol information associated.
if you really see a symbol with visibility hidden in the dynamic symbol table then this is a bug.
So could I infer that
- `Version symbol' entries are greater than 1 if and only if the
concerned library(or DSO) uses symbol versioning.
Yes. But there is no version definition section at all if symbol versioning is not used.
- And if so, there is no way of knowing if a *local* symbol is defined in
the same object/binary or is resolved from a library while running?
A symbol that is referenced and uses a PLT slot will use the well-defined symbol lookup path. That's the whole point of ELF symbol lookup. Read
http://people.redhat.com/drepper/dsohowto.pdf
section 1.5.4.
Hello Ulrich, thanks a lot for the reply.
On Tue, 28 Apr 2009, Ulrich Drepper wrote:
But hidden symbols shouldn't be in the dynamic symbol table and only symbols in the dynamic symbol table have version symbol information associated.
Right! Sorry, I didn't see the hidden symbols were under .symtab, really sorry!
- `Version symbol' entries are greater than 1 if and only if the
concerned library(or DSO) uses symbol versioning.
Yes. But there is no version definition section at all if symbol versioning is not used.
Yes true.
A symbol that is referenced and uses a PLT slot will use the well-defined symbol lookup path. That's the whole point of ELF symbol lookup. Read
http://people.redhat.com/drepper/dsohowto.pdf section 1.5.4.
Sure, I'll do that.
Thanks so much. -- Regards - Prasad
elfutils-devel@lists.fedorahosted.org
-
P J P -
Roland McGrath -
Ulrich Drepper