Re: [Valgrind-developers] Re: callgrind for Valgrind 3.0.X

[John R. <jr...@Bi...>]

> ... The easiest way would be to look at the symbol "dl_runtime_resolve".
> I just do not understand why this symbol on some systems seems not to be
> available. ...

The glibc developers have decided that _dl_runtime_resolve is a private
symbol internal to glibc, and that it is nobody else's business.  So
in a somewhat-recent "sanitizing pass", they removed _dl_runtime_resolve
from the list of exported symbols.
(They did the same thing earlier with _dl_relocate_object, but that one
is so important that I re-export it when I build audited glibc.  See
http://BitWagon.com/glibc-audit/glibc-audit.html )

For any module that actually does any resolving, _dl_runtime_resolve
will appear in _GLOBAL_OFFSET_TABLE_[2].  This is specified in the
Application Binary Interface (ABI), and it the client code in the
executable application's Procedure Linkage Table (PLT) depends on it,
so it will "never" change.  See "System V Application Binary Interface,
x86-64 Architecture Processor Supplement" [google for it].  The catch is
that a module which is 100% pre-linked [with no conflicts] does not do
any resolving, so GOT[2] will be 0 in that module.

For each particular architecture, the implementation of _dl_runtime_resolve
is in hand-written assembly language.  Thus it changes rarely, has a
distinctive signature, and can be found quickly and reliably by a
string search of the entire .text PT_LOAD of the runtime loader.
To figure out the string to search for, look with gdb on a
non-stripped ld-linux.

--