From mboxrd@z Thu Jan  1 00:00:00 1970
From: trost@cloud.rain.com (Bill Trost)
Date: Wed, 06 Jun 2012 07:48:17 -0700
Subject: [lttng-dev] using --function/--probe
In-Reply-To: Your message of Tue, 05 Jun 2012 11:49:50 EDT.
	<20120605154950.GA21955@Krystal>
References: <20120605154950.GA21955@Krystal><3551.1338647739@cloud.rain.com>
Message-ID: <19046.1338994097@cloud.rain.com>

Mathieu wrote:
    * Bill Trost (trost at cloud.rain.com) wrote:
    > and how does it differ from "--probe"? How do I determine
    > what symbols are valid for each of these options?

    It entirely depends on which functions are blacklisted in the kernel
    (this is an attribute added to the functions specifically for kprobes).
    The keyword is "__kprobes".

Is that the only basis? For example, I can add a dynamic tracepoint (of
either flawor) for queue_work_on(), but not work __queue_work(), yet
neither of those functions have any apparent annotation. Or does
EXPORT_SYMBOL_GPL imply a probe point?

    > ...how do I trace what work is being
    > enqueued and run by the kworker threads?

    For this level of details, I think kprobes/kretprobes will not
    currently allow you to fetch it. The two options we have are:

    - use static tracepoints. Is there a tracepoint that targets the
      information you are looking for ? Try "lttng list -k".

No, I've been capturing all kernel events and haven't seen
anything resembling the kworker tracepoints of lttng 0.x.

    - or extend the dynamic probing to allow fetching variables from
      debug information,

Hmm. Well, I did a bit more poking and got a bit closer -- at least now
I know what dynamic points to use. (eg, "queue_work_on" and friends to
see what is being queued). I take it that LTT can't capture function call
arguments as a form of additional context? That would be an ideal
bit of information in this case.

Thanks again,
Bill