[Lldb-commits] [PATCH] Strip ELF symbol versions from symbol names

[Pavel Labath]

Thanks a lot for your replies, they have been most helpful. I will
investigate the solution proposed by Greg and will get back to you.


> How does the linker actually fix up the libraries using these symbols to
point to the right one?  In Mac OS X the equivalent task is achieved by
having a symbol of type "resolver" that is actually called memcpy, and when
the
> linker needs to call that function, it knows that it should call the
resolver function, and that will return the address of the correct
implementation.  So in lldb, we don't have to try to guess what the linker
is going to do, we can just
> call this function to get the target symbol.  This can't change over the
running of the program so we cache the target address of the resolver
symbol.

I don't know much about this, as I have just started studying this problem,
but my understanding is the following: The library can depend on a specific
version of the symbol. If it does then the dynamic linker just picks that.
If the library does not specify the version, then the linker just picks the
default. This means that within a single process you could have many shared
libraries, each one using a different version of the symbol. So yes,
setting a breakpoint should find all of these functions.

The actual implementation of this is quite elaborate and there are several
file sections which exist solely for this purpose (.gnu.version,
.gnu.version_d, .gnu.version_r), which we currently just ignore.


> Someday I plan to add a symbol search command that will be able to find
symbols by regex if nobody beats me to it.  That would also be a consumer
of symbol names.
I think such a facility already exists. You can already set a breakpoint by
a regular expression "breakpoint set --func-regex"). Not sure if regexes
can be used in other situations though...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150227/1779477f/attachment.html>