Re: MIPS RT debug support

2007-11-16 Thread john cooper
Steven Rostedt wrote: IIRC, only CALLER_ADDR0 is actually used (I've found that the others are mostly unreliable). I seem to recall more use was made of __builtin_return_address(n) for 0 < n in the past compared to the current code. Likely for shallow frames the 0 < n calls were potentially

Re: MIPS RT debug support

2007-11-16 Thread john cooper
Steven Rostedt wrote: IIRC, only CALLER_ADDR0 is actually used (I've found that the others are mostly unreliable). I seem to recall more use was made of __builtin_return_address(n) for 0 n in the past compared to the current code. Likely for shallow frames the 0 n calls were potentially

Re: MIPS RT debug support

2007-11-15 Thread Steven Rostedt
On Thu, 15 Nov 2007, john cooper wrote: > > It isn't an issue of getting a hook into the FUNCTION_PROLOGUE > (mcount() here) but rather of emulating the CALLER_ADDR[0123] > defs which map onto the gcc internal __builtin_return_address(). > Doing so using the affectionately dubbed "Three Stooges

Re: MIPS RT debug support

2007-11-15 Thread john cooper
Steven Rostedt wrote: On Thu, 15 Nov 2007, Tim Bird wrote: john cooper wrote: The more daunting problem stems from limitations in the MIPS ABI which makes the latency trace support problematic. Rather than rehash the issue: http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html Until

Re: MIPS RT debug support

2007-11-15 Thread Steven Rostedt
On Thu, 15 Nov 2007, Tim Bird wrote: > john cooper wrote: > > The more daunting problem stems from limitations in the MIPS > > ABI which makes the latency trace support problematic. > > Rather than rehash the issue: > > > > http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html > > > >

MIPS RT debug support

2007-11-15 Thread Tim Bird
john cooper wrote: > The more daunting problem stems from limitations in the MIPS > ABI which makes the latency trace support problematic. > Rather than rehash the issue: > > http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html > > Until we have a usable instrumentation solution in

MIPS RT debug support

2007-11-15 Thread Tim Bird
john cooper wrote: The more daunting problem stems from limitations in the MIPS ABI which makes the latency trace support problematic. Rather than rehash the issue: http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html Until we have a usable instrumentation solution in place,

Re: MIPS RT debug support

2007-11-15 Thread Steven Rostedt
On Thu, 15 Nov 2007, Tim Bird wrote: john cooper wrote: The more daunting problem stems from limitations in the MIPS ABI which makes the latency trace support problematic. Rather than rehash the issue: http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html Until we have a

Re: MIPS RT debug support

2007-11-15 Thread Steven Rostedt
On Thu, 15 Nov 2007, john cooper wrote: It isn't an issue of getting a hook into the FUNCTION_PROLOGUE (mcount() here) but rather of emulating the CALLER_ADDR[0123] defs which map onto the gcc internal __builtin_return_address(). Doing so using the affectionately dubbed Three Stooges

Re: MIPS RT debug support

2007-11-15 Thread john cooper
Steven Rostedt wrote: On Thu, 15 Nov 2007, Tim Bird wrote: john cooper wrote: The more daunting problem stems from limitations in the MIPS ABI which makes the latency trace support problematic. Rather than rehash the issue: http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html Until