https://bugs.kde.org/show_bug.cgi?id=415293
--- Comment #10 from Josef Weidendorfer <josef.weidendor...@gmx.de> ---
Original Callgrind author here...
Sorry for not checking my old email address for open-source projects obviously
for almost 1 1/2 years... just see this now, as I was checking out callgrind on
recent Ubuntu and found it not working any more (partly due to this issue).
First: thanks for this very elaborated patch!
Two remarks:
- there is no "_dl_runtime_resolve_xsave'2" - the ending "'2" is
generated by callgrind notifying "recursion level 2" - ie it's the same
function, just found for the 2nd time on the call stack. As by default
the recursion level is max'ed at 2, it probably includes all higher levels
- the complex "check_code" function really only should be required when
the symbols are stripped from the runtime linker, as last resort to
still be able to do the special handling...
Trying to make this work on more architectures and recent glibc's, my
suggestion
is to add this patch for callgrind/fn.c:
- if (VG_(strcmp)(fn->name, "_dl_runtime_resolve")==0) {
+ if (VG_(strncmp)(fn->name, "_dl_runtime_resolve", 19)==0) {
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, I do not think this prefix is 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.
The whole issue to solve here is that the call chain
A -(call)-> B -(tail call)-> C (with B being "_dl_runtime_resolve*")
should be interpreted as A calling B, returning to A, calling C.
Why? Because "_dl_runtime_resolve*" is some kind of dispatcher function,
with a large number of calls routed through it. And this scenario is
bad for profile analysis when only having a single caller as context.
The replacement shows (1) better information, (2) reduces the probability
of a recursive function cycle - which obscures profiling results, and
(3) is less confusing to users not aware of the runtime linker.
Note: the patch applied as fix can stay, as it allows for a stripped
runtime linker.
--
You are receiving this mail because:
You are watching all bug changes.
