Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return

From: Ingo Molnar
Date: Tue Nov 11 2008 - 12:15:18 EST



* Frédéric Weisbecker <fweisbec@xxxxxxxxx> wrote:

> > 2) i cleaned up the arch/x86/Kconfig impact:
> >
> > f1c4be5: tracing, x86: clean up FUNCTION_RET_TRACER Kconfig
>
>
> Ok.
> And concerning the constraint fixed in assembly. That's strange my
> compiler didn't even warn me about it.

yep, that's common with assembly constraints - often the bugs will
only trigger with certain compilers and with certain config options.
Generally we've got enough variations of these parameters in -tip
testing (randconfig plus multiple tools versions) to reliably trigger
such issues.

> > So lets use "function_full" and "function" tracing perhaps? The
> > "full" tracer is what traces both entry and exit points, and
> > establishes full function-call timings/costs. The "function"
> > tracer is more lightweight and traces function entry events.
>
> Right. I first chose function_return but it was the largest tracer
> name and so raised a bug that has been corrected since. And I kept
> this confusing name.
>
> I'm not sure function_full is really the good one because it's not
> really a full version of the function tracer. It doesn't do the same
> thing: when you look into a trace done by the function tracer, the
> functions appear in order of their call whereas with the function
> return tracer, they appear in the order of their return which is not
> the same. The effect is not the same. Why not function_return or
> something like that?

at the risk of bikeshed-painting this issue too much, the problem with
function_return is that it has little meaning to actual users and even
to developers. What does the "return" mean? We know what it means,
because we know that opposed to function entry we'll also capture
function returns, and hence be able to do full function call tracing.

so function_full i thought to conduct this aspect of it better. But
suggestions are welcome.

Ingo
--
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/