[lttng-dev] [RFC] Dynamic instrumentation support in UST

Zifei Tong soariez at gmail.com
Mon Jul 29 09:05:57 EDT 2013


On Sat, Jul 27, 2013 at 1:40 AM, Simon Marchi <simon.marchi at polymtl.ca> wrote:
> Hi Zifei,
>
> That looks great! Questions and comments below.
>
> On 26 July 2013 11:40, Zifei Tong <soariez at gmail.com> wrote:

Thanks.

>
> What is the difference if I do
>   --function foo
> vs
>   --probe foo
> ?
>

Good point, i've updated the RFC:

You can also enable a tracepoint at the entry/return of a given function:

     lttng enable-event NAME -u --pid PID
         --function (addr | symbol | symbol+offset)
                             Dynamic UST function entry/return probe.
                              Addr and offset can be octal (0NNN...),
                              decimal (NNN...) or hexadecimal (0xNNN...)

This will place a bare probe at the entry and return point of certain function.

In this way, `lttng enable-event -k --function` and `lttng
enable-event -u --function` will behave similar.

This could be implemented using dyninst straightforwardly (with
BPatch_entry, BPatch_exit), or somehow find a way to warp the
function.

>
> Does it make sense to put collected variable values in the context? I
> would instinctively put them as event fields. Backtrace and registers
> are probably more of a context though. Either way, it will require the
> use of per-event context. I don't think that this feature has been
> very much tested in the CTF parsers (looking at the ctf testsuite), so
> it will be a good test :)
>

I cannot find a more relevant existing command. I am thinking if it is
possible to reuse the add-context
command but put these data (registers, memory values) as event fields instead.

>
> You have to think about instructions that act relatively to the
> current ip. These have to be adjusted to give the correct result. See:
> https://github.com/MentorEmbedded/Debug-Agent-Library/blob/master/x86-64-linux-backend.c#L239
>

Yes, you are right. This is just kind of pseudo code to demonstrate
the concept. I'll take care when implementing it [1].

[1]: https://github.com/5kg/lttng-gsoc/blob/master/kaji/kaji.c#L134

Thanks,
Zifei Tong



More information about the lttng-dev mailing list