Re: Human readable output for function return tracer

From: Frédéric Weisbecker
Date: Mon Nov 24 2008 - 12:35:11 EST


2008/11/24 Steven Rostedt <rostedt@xxxxxxxxxxx>:
> A little off topic, but how do you handle collapsed returns?
>
> func1() {
> [...]
> func2();
> return;
> }
>
> Instead of using call *func2, gcc may decide to collapse it. That is,
> since it is the last thing done on func1, it may pop func1's frame all the
> way to func1's return address, and then do a "jmp" to func2. func2 will
> still call mcount, but on its return, it will jump to the func1 return
> address.
>
> Perhaps this is OK. The call to func1's mcount will store the original
> return address and replace it with the function return code. The call to
> func2 will store that return address and replace it with the func2
> function return code. And both of them will still be processed.
>
> OK, I think I answered my own question, but I'm keeping it in this post
> just to make sure I understand it correctly.


Yes, perhaps it is done that way. Or perhaps CONFIG_FRAME_POINTER avoids
such collapsing calls... I don't know.
Perhaps I should look at some disassembly dumps to ensure things are safe, but
I didn't have any problem with that...


> Do you have a record that you store when you make the first mcount call.
> In this record, could you save the depth of the parent there too. I do not
> remember the code exactly, so I might be off here ;-)

No. At this time I don't do any insertion at the call time :-)
But I don't think I will need the parent depth. The current depth will
be sufficient for the trace printing.
--
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/