[Ltrace-devel] Support for systemtap probes in ltrace

[Petr Machata]

Steve Fink <sphink at gmail.com> writes:

> On Mon, Aug 8, 2011 at 3:54 AM, Petr Machata <pmachata at redhat.com> wrote:
>> Steve Fink <sphink at gmail.com> writes:
>>
>>> On Sat, Aug 6, 2011 at 6:58 PM, Petr Machata <pmachata at redhat.com> wrote:
>>>> Hi there,
>>>>
>>>> SDT probes are used by some application--typically, they are placed to
>>>> "strategic" places, such as when MySQL parses a query, or when OpenJDK
>>>> compiles a method.  I believe it would be useful for ltrace to be able
>>>> to put breakpoints on these.
>>>
>>> I will soon be adding Firefox to that list (well, really just the
>>> Javascript interpreter within Firefox). But that makes me curious --
>>> how are you planning to use this functionality?
>>
>> I don't plan adding SDT probes to ltrace, I want ltrace to be able to
>> "see" and trace the probes.  Is that what you had in mind?
>
> Yes. I've added SDT probes to Firefox, and hope to enable them in the
> default build soon. As I understand it, your work would allow running
> ltrace on an application containing SDT probes and see the shared
> library calls plus the static probes. I can see how that would be

Yes.  I expect there to be an option that would turn on the probes.

> theoretically useful (eg to only consider library calls after a MySQL
> query was parsed to avoid startup cruft, or only look between start
> and end markers of a garbage collection run in Firefox.) But I'm
> curious if you have specific use cases in mind. I'm planning to

I'm afraid I don't have use for this myself.  I rarely use debuggers in
fact, but apparently they are useful to _some_ people.  And since other
people keep adding SDT probes to applications, these must convey an
interesting information.  Tracing them then fits the bill of ltrace.
They are actually easier to implement than library calls, too--no need
to meddle with PLT, no need to figure out return breakpoints and to do
the cumbersome pointer removal/reenablement, since you can simply skip
over the breakpoint.

> collect a set of (hopefully) compelling examples of when this sort of
> tracing stuff is useful, and it'd be great to add an ltrace example to
> the list. Especially since it would show that inserting these probes
> is more generally useful than just being able to write systemtap
> scripts that make use of them. But I don't want to argue that in the
> abstract; I want concrete examples of where it would be useful for
> actual problems/analyses.

Honestly, I'm not quite sure what people use ltrace for.  I guess the
use case is "easier to learn than systemtap, yet somewhat useful".  Or
perhaps "less invasive than systemtap", what with all the kernel module
wizardry implied in using systemtap.  I'm not really sure.  The point
being, I'm writing this because I think whoever uses ltrace might have a
use for this, too.  But really, I don't know.

Um, I don't think I helped you much, have I? ;)

PM