]> git.ipfire.org Git - thirdparty/valgrind.git/commit
Callgrind: Broader handling of _dl_runtime_resolve variants
authorJosef Weidendorfer <Josef.Weidendorfer@gmx.de>
Wed, 7 Apr 2021 22:34:48 +0000 (00:34 +0200)
committerJosef Weidendorfer <Josef.Weidendorfer@gmx.de>
Wed, 7 Apr 2021 22:50:00 +0000 (00:50 +0200)
commit5e41080720e451cefc2265c64f82fb77a9f29151
tree4a3aafb8e22396a6488752b64a0006128dc96488
parent19cae12c175904c30a751e3450b1a2cd412759dd
Callgrind: Broader handling of _dl_runtime_resolve variants

This is a supplement to commit 86277041

To improve its results, Callgrind does special handling for
the runtime linker entry point to resolve symbols. However,
it only used the exact symbol name "_dl_runtime_resolve",
as well as specific machine code templates (when the runtime
linker was stripped from symbol names) as basis.
Recent glibc added multiple similar symbol names as variants,
such as _dl_runtime_resolve_xsave.

The above-mentioned commit 86277041 solves this by extending
the check for machine code templates for specific Linux
distributions.
This patch extends this for more architectures and variants
by checking if a function starts with "_dl_runtime_resolve".
Furthermore, the original function names of the variants
still are visible in the output (and not forced to the prefix).

While the heuristic that every function symbol starting
with the prefix "_dl_runtime_resolve" as being an entry point
into the runtime linker for resolving a function address may
be a bit rough, this prefix is not expected to be used often in
other source code for anything else.

The worst case is a slightly misleading call graph only
visible in a very specific situation: if the wrongly-detected
function does a tail call (ie instead of returning, jumping
to another function), it will be shown as 2 calls in a row
from the original caller.
callgrind/fn.c