Re: tracing: confusing output of function_graph when notrace functioncalls traceable function

[Tim Bird]

>Steven Rostedt wrote:
>>On Wed, 2010-01-06 at 14:08 +0100, Jiri Olsa wrote:
>>> On Wed, Jan 06, 2010 at 06:44:02PM +0800, Lai Jiangshan wrote:
>>> == real graph ==:
>>>
>>> father_fun()
>>>   child_fun()
>>>   notrace_child_fun()
>>>     grandchild_fun1()
>>>     grandchild_fun2()
>>>
>>> ===function_graph shows===>
>>>
>>> father_fun()
>>>   child_fun()
>>>   grandchild_fun1()
>>>   grandchild_fun2()
>>>
>>> When the notrace function calls traceable function, function_graph will
>>> get wrong depth of functions, and show wrong graph.
>>>
>>> Is there any method to fix it?
>> I dont think so..
>>
>> AFAIK the depth computation is based on the traced functions, and there's
>> no other 'depth related' input apart from them.
> 
> Right.
> 
> 
> Honestly, if you think about it, the "father_fun()" does call those
> grandchild_fun() functions. Just indirectly. I don't find anything wrong
> with this.
> 
> You get the same issue if gcc decides to inline a function, since those
> inlined functions don't get traced either.

Well, there is at least one thing different that could be used to indicate
that we're "down" farther in the call nesting, and that is stack depth.
In the example above, grandchild_fun1() is going to have a lower stack position
than child_fun().  So you might be able to use 'sp' to distinguish between
children and lower descendents.

You could potentially use this as an indicator for increased
indentation, but I'm not sure how accurate it is.
This might be different from the inline case, where the compiler usually
does not build a stack frame for the "called" code.  But you also might
get false positives from variables declared inside in-function blocks
(or from other compiler oddities).

I would lean towards Steve's answer, that it doesn't matter too much.
Invisibility in the trace log, and the possible confusion it creates,
is the price you pay for 'notrace'.

Just my 2 cents.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/