lkml.org 
[lkml]   [2008]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Human readable output for function return tracer
2008/11/24 Steven Rostedt <rostedt@goodmis.org>:
> 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.


\
 
 \ /
  Last update: 2008-11-24 18:37    [W:0.661 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site