[lttng-dev] [RFC] Dynamic instrumentation support in UST
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:
> What is the difference if I do
> --function foo
> --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
> 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:
Yes, you are right. This is just kind of pseudo code to demonstrate
the concept. I'll take care when implementing it .
More information about the lttng-dev