ltrace for ppc

ltrace for ppc

[Anton Blanchard]

Hi,

ltrace is a cool little program for tracing library calls. I ported it
to ppclinux a while ago but the ltrace maintainer seems to have ignored
my patch.

For anyone interested the patch can be found at:

http://linuxcare.com.au/anton/patches/ltrace_ppc_patch

It should apply cleanly to the latest source (I got mine from the debian
archive).

Anton

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Daniel Jacobowitz]

On Wed, Feb 14, 2001 at 08:10:00AM +1100, Anton Blanchard wrote:
>
> Hi,
>
> ltrace is a cool little program for tracing library calls. I ported it
> to ppclinux a while ago but the ltrace maintainer seems to have ignored
> my patch.
>
> For anyone interested the patch can be found at:
>
> http://linuxcare.com.au/anton/patches/ltrace_ppc_patch
>
> It should apply cleanly to the latest source (I got mine from the debian
> archive).

You did?  Wow!  I spent ages trying to do this...

Oh, looking at your patch I remember what happened.  It's a bloody
miracle that ltrace works at all on any architecture; the PLT tricks
that the PPC plays are not at all uncommon, as I recall.  I got
derailed trying to make it insert breakpoints at the proper time.

Thanks for the patch; I'll probably keep bugging the author about
this...

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Karim Yaghmour]

If you're interested in ltrace, you may want to take a look at the
Linux trace toolkit (http://www.opersys.com/LTT). It runs fine
on PPC too.

Best regards,

Karim

Daniel Jacobowitz wrote:
>
> On Wed, Feb 14, 2001 at 08:10:00AM +1100, Anton Blanchard wrote:
> >
> > Hi,
> >
> > ltrace is a cool little program for tracing library calls. I ported it
> > to ppclinux a while ago but the ltrace maintainer seems to have ignored
> > my patch.
> >
> > For anyone interested the patch can be found at:
> >
> > http://linuxcare.com.au/anton/patches/ltrace_ppc_patch
> >
> > It should apply cleanly to the latest source (I got mine from the debian
> > archive).
>
> You did?  Wow!  I spent ages trying to do this...
>
> Oh, looking at your patch I remember what happened.  It's a bloody
> miracle that ltrace works at all on any architecture; the PLT tricks
> that the PPC plays are not at all uncommon, as I recall.  I got
> derailed trying to make it insert breakpoints at the proper time.
>
> Thanks for the patch; I'll probably keep bugging the author about
> this...
>
> Dan
>
> /--------------------------------\  /--------------------------------\
> |       Daniel Jacobowitz        |__|        SCS Class of 2002       |
> |   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
> |         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
> \--------------------------------/  \--------------------------------/
>

--
===================================================
                 Karim Yaghmour
               karym@opersys.com
          Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===================================================

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Iain Sandoe]

> If you're interested in ltrace, you may want to take a look at the
> Linux trace toolkit (http://www.opersys.com/LTT). It runs fine
> on PPC too.

I'm *very* interested in any toolkit that can provide point-to-point
_timing_ of system calls, IRQ handling, system usage. latency etc. etc. (a
la TIMEPEGS or Andrew Morton's amlat on x86).

what do we have (existing) on PPC?

I did an IRQ latency thing on 2.2.x and Cort has proposed using RTlinux to
make IRQ measurements (well, I think he's done it, actually)...  that will
give headlines - but not tell us which drivers/functions are the rouges.

I was considering doing a port of Andrew Morton's stuff - but got stuck when
I tried to run with HZ=1024 - it trashed adb... and I haven't got back to it
yet.

ciao,
Iain

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Tony Mantler]

At 3:10 PM -0600 2/16/2001, Iain Sandoe wrote:
>> If you're interested in ltrace, you may want to take a look at the
>> Linux trace toolkit (http://www.opersys.com/LTT). It runs fine
>> on PPC too.
>
>I'm *very* interested in any toolkit that can provide point-to-point
>_timing_ of system calls, IRQ handling, system usage. latency etc. etc. (a
>la TIMEPEGS or Andrew Morton's amlat on x86).
>
>what do we have (existing) on PPC?
>
>I did an IRQ latency thing on 2.2.x and Cort has proposed using RTlinux to
>make IRQ measurements (well, I think he's done it, actually)...  that will
>give headlines - but not tell us which drivers/functions are the rouges.
>
>I was considering doing a port of Andrew Morton's stuff - but got stuck when
>I tried to run with HZ=1024 - it trashed adb... and I haven't got back to it
>yet.

What about SGI's Kernprof stuff? <http://oss.sgi.com/projects/kernprof/>.

I was going to poke at it to see if/what it breaks a while back when there
was some talk of weird SMP slowdowns, but I think I got sidetracked with
something else.

Anyways, it's probably worth looking into.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Anton Blanchard]

> What about SGI's Kernprof stuff? <http://oss.sgi.com/projects/kernprof/>.

It should be easy to port this and SGI's lockmeter (spinlock metering)
to PPC if they haven't already been. I ported them to sparc64 a while ago
and they have been quite useful.

Anton

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Thomas Graichen]

Anton Blanchard <anton@linuxcare.com.au> wrote:


>> What about SGI's Kernprof stuff? <http://oss.sgi.com/projects/kernprof/>.

> It should be easy to port this and SGI's lockmeter (spinlock metering)
> to PPC if they haven't already been. I ported them to sparc64 a while ago
> and they have been quite useful.

also ask on the kernprof/lockmeter list first before you start
hacking yourself - i think there was someone working on porting
it to ppc already (but i am not absolutely shure)

t

--
thomas.graichen@innominate.com
                                                         innominate AG
                                                  the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Karim Yaghmour]

Iain Sandoe wrote:
>
> > If you're interested in ltrace, you may want to take a look at the
> > Linux trace toolkit (http://www.opersys.com/LTT). It runs fine
> > on PPC too.
>
> I'm *very* interested in any toolkit that can provide point-to-point
> _timing_ of system calls, IRQ handling, system usage. latency etc. etc. (a
> la TIMEPEGS or Andrew Morton's amlat on x86).

LTT will definitely give all this and more. It will give you IRQ timings
precise down to the microsecond, same with system calls and any latency.
The measurements it gives are exact, not sampled. Everything you get
corresponds exactly to what happened on your hardware down to the microsecond.
It runs fine on my PowerBook. Give a try and let me know what you think.

>
> what do we have (existing) on PPC?
>
> I did an IRQ latency thing on 2.2.x and Cort has proposed using RTlinux to
> make IRQ measurements (well, I think he's done it, actually)...  that will
> give headlines - but not tell us which drivers/functions are the rouges.

LTT will give you the breakdown of how Linux reacts to each IRQ and it is
extendable. Therefore, if you'd like to insert additional trace points in a
driver or another or even an uninstrumented part of the kernel, you'll be able
to create new trace events and see them as part of the trace.

> I was considering doing a port of Andrew Morton's stuff - but got stuck when
> I tried to run with HZ=1024 - it trashed adb... and I haven't got back to it
> yet.

About Andrew Morton's stuff, any pointers?

Best regards,

Karim

===================================================
                 Karim Yaghmour
               karym@opersys.com
          Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===================================================

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Iain Sandoe]

> What about SGI's Kernprof stuff? <http://oss.sgi.com/projects/kernprof/>.
>
> I was going to poke at it to see if/what it breaks a while back when there
> was some talk of weird SMP slowdowns, but I think I got sidetracked with
> something else.
>
> Anyways, it's probably worth looking into.

looks like another potential.  no ppc support that I can see in the patch...
so, I guess, like AM's stuff, that's all TODO.

thanks for the URL,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Iain Sandoe]

Thanks Karim - I hate re-inventing wheels...

Karim Yaghmour wrote:
> Iain Sandoe wrote:
>>
>> > If you're interested in ltrace, you may want to take a look at the
>> > Linux trace toolkit (http://www.opersys.com/LTT). It runs fine
>> > on PPC too.
>>
>> I'm *very* interested in any toolkit that can provide point-to-point
>> _timing_ of system calls, IRQ handling, system usage. latency etc. etc. (a
>> la TIMEPEGS or Andrew Morton's amlat on x86).
>
> LTT will definitely give all this and more. It will give you IRQ timings
> precise down to the microsecond, same with system calls and any latency.
> The measurements it gives are exact, not sampled. Everything you get
> corresponds exactly to what happened on your hardware down to the microsecond.
> It runs fine on my PowerBook. Give a try and let me know what you think.

with copy like that... I can't resist ;-)

As soon as time permits I will try it (still got some dmasound stuff in the
works).

>> what do we have (existing) on PPC?
>>
>> I did an IRQ latency thing on 2.2.x and Cort has proposed using RTlinux to
>> make IRQ measurements (well, I think he's done it, actually)...  that will
>> give headlines - but not tell us which drivers/functions are the rouges.
>
> LTT will give you the breakdown of how Linux reacts to each IRQ and it is
> extendable. Therefore, if you'd like to insert additional trace points in a
> driver or another or even an uninstrumented part of the kernel, you'll be able
> to create new trace events and see them as part of the trace.

cool.

>> I was considering doing a port of Andrew Morton's stuff - but got stuck when
>> I tried to run with HZ=1024 - it trashed adb... and I haven't got back to it
>> yet.
>
> About Andrew Morton's stuff, any pointers?

http://www.uow.edu.au/~andrewm/linux/

thanks,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Iain Sandoe]

> It runs fine on my PowerBook. Give a try and let me know what you think.

I'm missing something here... ibm's DProbe page says "i386 only" and their
patch doesn't appear to have any ppc code...

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ltrace for ppc

[Karim Yaghmour]

LTT doesn't need DProbes although it can interact with it.
The custom-event facility is proper to LTT, DProbes uses
it to log its events, but the information gathered by
LTT isn't gathered by means of DProbes. LTT can get the
information it has because the kernel is patched accordingly
to call on LTT upon the occurrence of crucial events.

Here's an excerpt from the exception handler on the PPC:
void
_exception(int signr, struct pt_regs *regs)
{
	if (!user_mode(regs))
	{
		show_regs(regs);
#if defined(CONFIG_XMON) || defined(CONFIG_KGDB)
		debugger(regs);
#endif
		print_backtrace((unsigned long *)regs->gpr[1]);
		panic("Exception in kernel pc %lx signal %d",regs->nip,signr);
	}
	TRACE_TRAP_ENTRY(regs->trap, instruction_pointer(regs));
	force_sig(signr, current);
	TRACE_EVENT(TRACE_EV_TRAP_EXIT, NULL);
}

Notice the TRACE_TRAP_ENTRY statement. It is in fact a macro.
If you compile the kernel with trace support, then this will
result in a call to trace_event() which is a kernel-global entry
point for all events. Even then, the event may be ignored. This
will depend on whether a trace driver (provided with LTT) is
loaded or not. If it is loaded and registered with the
kernel trace facility, then events will be forwarded onto it.
Still, the events may be ignored by the trace driver if the
trace daemon hasn't opened the device and is waiting for a
signal from it. All this is to minimize intrusion on the kernel's
operation. If the kernel is compiled without trace support
then the macro results in no code at all.

Hence, you are correct, DProbes is for "i386 only" (although you
may be interested to know that I've spoken with the project
manager and they don't intend to keep this a ix86-specific thing.)
DProbes is interesting if you want to add tracepoints _dynamically_,
this LTT can't do. For LTT to operate, the tracepoints have to
be applied to the kernel's sources. (No need to say that I'd like
LTT to be part of the standard kernel sources as it isn't a
kernel debugger and is non-intrusive as to the normal behavior of
the kernel).

Note that PPC support is available in the 0.9.4preX series of LTT,
not in 0.9.3.

Best regards,

Karim

Iain Sandoe wrote:
>
> > It runs fine on my PowerBook. Give a try and let me know what you think.
>
> I'm missing something here... ibm's DProbe page says "i386 only" and their
> patch doesn't appear to have any ppc code...
>
> Iain.

--
===================================================
                 Karim Yaghmour
               karym@opersys.com
          Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===================================================

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/