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

[Suchakra Sharma]

Hi,

First of all, I think its very well written :)

On Fri, 2013-07-26 at 23:40 +0800, Zifei Tong wrote:

>     lttng add-context -u -e NAME --pid PID
>         -t, --type TYPE     Context type.
>                             TYPE can be one of the strings below:
>                                 regs
>                                     all registers
>                                 reg:reg_name
>                                     register with name reg_name
>                                 var_type:var_name:addr
>                                     variable at addr with field name var_name
>                                 backtrace
>                                     stack backtrace
> 
> Examples:
> 
>     # lttng add-context -u --pid PID -e aname -t reg:rax
>     # lttng add-context -u --pid PID -e aname -t int:varname:0xdeadbeef
>     # lttng add-context -u --pid PID -e aname -t string:varname:0xdeadbeef
>     # lttng add-context -u --pid PID -e aname -t backtrace

I had an idea about having these 'preset' (or some other fancy name)
types of events rather than different contexts. For eg.

	#lttng enable-event -u --pid PID --preset reg:rax

Thats how I had this is my mind. But I don't know a lot yet so I don't
know which is better.

> These context types appear in other tracers [4],[5],[6], however
> implement all of
> them may be not possible within the GSoC schedule.
> 
> The above proposed command line interface require defining tracepoint event at
> runtime thus free user form compiling tracepoint probes themselves. But I have
> a concern such runtime defined tracepoint event mechanism may eventually evolve
> to a tiny compiler/interpreter like Systemtap [7] or gdb [8].

Of course, to provide more flexibility it has to be evolved to a
mechanism by which through a meta language or some scripts, the
tracepoints can be compiled. Its going to be complex, but thats what
this should evolve into slowly. I don't think it should be of concern.

> 
> Implementation
> --------------
> 
> After comparing dyninst with gdb's tracepoint code, I think using dyninst as
> current choice of implementing dynamic instrumentation is more appropriate.
> gdb's tracepoint function relies on a lot of support code they already have,
> such as disassembler, elf/DWARF parser. We'll need to a lot of work to port all
> the support code.

Of course, dyninst will definitely provide a fast and clean
implementation (unless we have a library written from scratch to do
instrumentation) 

Not being overambitious but, eventually we may need to have options to
dynamically instrument binaries based on performances of gdb's strategy
as well as dyninst's strategy in different use cases. Systemtap already
has --runtime=dyninst switch to use dyninst or uprobe based (default)
instrumentation.


--
Suchakra