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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Nov 2008 18:24:21 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v3][PATCH 0/2] Make ftrace able to trace function return

2008/11/11 Ingo Molnar <mingo@...e.hu>:
>
> * Frédéric Weisbecker <fweisbec@...il.com> 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.


I love -tip testing :-)


>> > 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.


Ok. Let's change into function_full, after all, I think that this tool
will be mostly used  with a parsing pass
of its traces with a script to produce statistics and hierarchical
representation like does draw_functrace.py
After that, the order of apparition of the functions in the trace will
not really matter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/