[lttng-dev] 回复:Re: documentation about CTF event payload

[Mathieu Desnoyers]

Hi, 

(adding back lttng-dev in CC for the benefit of others) 

Whenever possible, we try to augment the trace data with such additional 
information at post-processing, because capturing it at run-time repeatedly ends 
up being costly. 

The lttng-analyses project contains state tracker which augment the trace data 
with mapping from file descriptor to corresponding file names (see lttnganalyses/linuxautomaton/io.py). 
I'm not sure if the Trace Compass project models this mapping between file descriptors and their 
associated file, but if not, it would be an *extremely* useful addition. 

lttng-modules already dumps the information needed to create that model: 

- lttng_statedump_file_descriptor dumps all existing file descriptors for all processes, 
- a few system calls (open, dup, dup2, dup3, close, clone(see CLONE_FILES flag), fork, 
fcntl(cmd==F_DUPFD)) allow tracking the file descriptor table state changes during the trace. 

Thanks, 

Mathieu 

----- On Nov 25, 2019, at 7:36 PM, 杨海 <hai.yang at magic-shield.com> wrote: 

> Hi Mathieu

> Thanks for quick response. Here let me give an example. For syscalls open, LTTng
> output filename in entry_open and output fd as ret in exit_open. It would be
> desired to output both filename and fd so we can correlate them.
> I am not sure whether there is a configuration that we can have the richest
> output regarding to syscalls.
> If not, we can modify lttng-modules to output what we need. Or any other
> recommendation?

> Regards
> Hai

> ----------

> 该邮件从移动设备发送

> --------------原始邮件--------------
> 发件人："Mathieu Desnoyers "<mathieu.desnoyers at efficios.com>;
> 发送时间：2019年11月20日(星期三) 晚上10:32
> 收件人："杨海" <hai.yang at magic-shield.com>;
> 抄送："lttng-dev "<lttng-dev at lists.lttng.org>;
> 主题：Re: [lttng-dev] documentation about CTF event payload
> -----------------------------------
> For the system call payload documentation, you might want to refer to the Linux
> system call
> man pages.

> For internal kernel tracepoints like sched_switch, there is no documentation of
> the meaning of
> each field at the moment. This state is the same as the upstream Linux kernel
> trace event. You'll
> have to figure it out on your own. Documenting each field of the ~500-1000 Linux
> kernel tracepoints
> is no small task.

> Thanks,

> Mathieu

> ----- On Nov 19, 2019, at 9:25 PM, 杨海 <hai.yang at magic-shield.com> wrote:

>> To be more specific, I suppose we can refer to
>> instrumentation\syscalls\3.10.0-rc7\x86-64-syscalls-3.10.0-rc7 for the payload
>> format of syscall event. Is it exactly in the CTF syscall event?

>> Regards
>> Hai
>> ------------------ Original ------------------
>> From: "杨海"<hai.yang at magic-shield.com>;
>> Date: Mon, Nov 18, 2019 09:54 AM
>> To: "lttng-dev"<lttng-dev at lists.lttng.org>;
>> Subject: documentation about CTF event payload
>> Hi

>> As LTTng generated CTF and babeltrace parse it, we have the output as attached.
>> We saw events such as sched_switch, but the payload cannot be understood
>> easily. Where we can find the document to explain the LTTng payload and
>> parameters?

>> Regards
>> Hai

>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20191126/4627b4ff/attachment.html>