Re: Human readable output for function return tracer

Ingo Molnar
2008-11-24T16:27:36Z

* Frédéric Weisbecker <fweisbec@gmail.com> wrote:

> Hi,
>
> I'm planning to apply an idea proposed by Ingo to make the output on
> the function return tracer
> more "eyes-parsable".
> The idea consists on a trace which has flow similar to C code:
>
> func1() {
> func2() {
> func3() {
> }
> }
> func4() {
> }
> }
>
> (With time of execution added on closing braces).
>
> The problem is that the traces arrive in the reverse order, according
> to the fact that functions
> are traced on return.
> The order corresponding to the above example would be as the following:
>
> func3, func2, func4, func1
>
> Oh and we have the parent in a return trace, so we would actually have:
>
> func2->func3

[ Note: here we'd also have: ]

func1->func2

> func1->func4
> .... ->func1

it's basicaly a representation of the callgraph in polish notation.

> This trace flow doesn't make the things easy to produce our C like
> code.
>
> So I found only one solution which have both pros and cons. I could
> send a "pre-trace" to the ring-buffer to signal that function x with
> depth y is beeing called (when we enter the function).

that's OK i think. It will double the number of events, but will
simplify everything immensely - especially if we have small
imperfections in the callgraph arising out of IRQ entries.

Note that we _could_ render it all from the return events alone,
because we have the full callgraph available. But it would be either
very memory-intense or very CPU-intense: we'd either have to buffer up
all the return events in a reverse-stack sort of construct (which
could grow much larger than the return stack itself), or we'd have to
reconstruct it on the fly by constantly scanning forwards to discover
the context of the printout. Both can have pretty ugly worst-case
behavior with certain call graph layouts.

So i think you made a good call - lets keep it simple for now.

Also, do you have any thoughts about how to extend the return-tracer
to 64-bit x86? It should work pretty well i think - the return value
has to be extended to 64 bits but that's pretty much all.

Ingo