* Harsh Bora (ha...@linux.vnet.ibm.com) wrote:
> On 01/09/2012 09:31 PM, Mathieu Desnoyers wrote:
>> * Harsh Prateek Bora (ha...@linux.vnet.ibm.com) wrote:
>>> Existing simple trace can log upto 6 args per trace event and does not
>>> support strings in trace record format. Introducing new trace format as
>>> discussed earlier on list to support variable number/size of arguments.
>>> (Ref: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg03426.html)
>>>
>>> Basic testing of this patch is successful. Stress testing not yet done.
>>>
>>> Apply patches, then run:
>>>
>>> make distclean
>>> ./configure with --enable-trace-backend=simple
>>> make
>>> sudo make install
>>>
>>> Sample tracelog showing strings support:
>>> [harsh@harshbora v9fs]$ scripts/simpletrace.py trace-events trace-23261
>>> v9fs_version 0.000 tag=65535 id=100 msize=8192 version=9P2000.L
>>> v9fs_version_return 17.530 tag=65535 id=100 msize=8192 version=9P2000.L
>>> v9fs_attach 180.121 tag=1 id=104 fid=0 afid=18446744073709551615
>>> uname=nobody aname=
>>>
>>>
>>> Note: LTTng ust backend is broken in upstream qemu, therefore tracetool.py
>>> doesnt support ust backend as of now. IIUC, ust's trace event APIs are under
>>> development and not yet stable.
>>
>> Hi,
>>
>> FYI, the LTTng-UST TRACEPOINT_EVENT API is very much stable as of now.
>> Even though we are still in LTTng-UST 2.0 prereleases, the fact that we
>> started the round of discussions on this API last summer makes us
>> confident that from this point on we should not have to change it.
>>
>> Moreover, I would like to know if the old UST 0.x (0.16 is the latest)
>> is broken wrt qemu, or if this is just for LTTng-2.0 UST support ?
>> UST 0.x instrumentation is not supposed to have broken wrt qemu.
>>
>
> Hi,
> Thanks for an early response. I had tried building with ust 0.16 and it
> gives compilation errors, specially for trace events with 'void'
> argument:
>
> CC osdep.o
> In file included from osdep.c:49:
> trace.h: In function ‘__trace_ust_slavio_misc_update_irq_raise’:
> trace.h:277: error: ‘void’ must be the only parameter
> trace.h:277: error: expected expression before ‘)’ token
> trace.h:277: error: too many arguments to function ‘(void (*)(void
> *))__tp_it_func’
> trace.h: At top level:
> trace.h:277: error: ‘void’ must be the only parameter
> trace.h:277: error: ‘void’ must be the only parameter
> In file included from osdep.c:49:
> trace.h: In function ‘__trace_ust_slavio_misc_update_irq_lower’:
> trace.h:280: error: ‘void’ must be the only parameter
> trace.h:280: error: expected expression before ‘)’ token
> trace.h:280: error: too many arguments to function ‘(void (*)(void
> *))__tp_it_func’
>
>
> I am not sure which interface is supposed to be used for void arguments
> in ust 0.16.
Looking at scripts/tracetool:
linetoh_ust()
{
local name args argnames
name=$(get_name "$1")
args=$(get_args "$1")
argnames=$(get_argnames "$1", ",")
cat <<EOF
DECLARE_TRACE(ust_$name, TP_PROTO($args), TP_ARGS($argnames));
#define trace_$name trace_ust_$name
EOF
}
for those tracepoints with argument "void", DECLARE_TRACE_NOARGS should
be used for UST 0.16. Similar for:
DEFINE_TRACE(ust_$name); -> DEFINE_TRACE_NOARGS(ust_$name);
> Moreover, if ust 2.0 uses different interfaces, we might
> want to use the latest one.
Note that this kind of special-case won't be needed with LTTng-UST 2.0
TRACEPOINT_EVENT. In place of DECLARE_TRACE, one would use:
TRACEPOINT_EVENT(qemu_kvm, $name,
TP_ARGS($args),
TP_FIELDS()
)
Note that I notice that some care will need to be taken to generate the
TP_FIELDS() from your existing trace-events file, an example:
g_realloc(void *ptr, size_t size, void *newptr)
would have to be translated to:
TRACE_EVENT(qemu_kvm, g_realloc,
TP_ARGS(void *, ptr, size_t, size, void *, newptr),
TP_FIELDS(
ctf_integer_hex(void *, ptr, ptr)
ctf_integer(size_t, size, size)
ctf_integer_hex(void *, newptr, newptr)
)
)
Note that the bright side is that the tracepoint probe does not need to
be hand-coded anymore, and there is no need to use the markers anymore
neither, which makes the tracer much faster.
For most of your fields (using %p, %d style format strings), you should
use ctf_integer or ctf_integer_hex (the latter lets the trace viewer
know that the data should be printed as hexadecimal).
You will likely need to detect the %s format strings you have there and
translate them into ctf_string(field, field) too. You can have a look at
lttng-ust tests/hello/*.[ch] for examples.
The call which would have looked like trace_qemu_kvm_g_realloc() in UST
0.x should now be done with:
tracepoint(qemu_kvm, g_realloc, ptr, size, newptr);
This is needed to (very soon) add support for sdt.h in LTTng-UST 2.0, so
systemtap and gdb can hook into tracepoints declared by lttng-ust 2.0.
Best regards,
Mathieu
>
> regards,
> Harsh
>
>> Best regards,
>>
>> Mathieu
>>
>>>
>>> Version History:
>>>
>>> v2:
>>> - Updated tracetool.py to support nop, stderr, dtrace backend
>>>
>>> v1:
>>> - Working protoype with tracetool.py converted only for simpletrace backend
>>>
>>> Harsh Prateek Bora (4):
>>> Converting tracetool.sh to tracetool.py
>>> Makefile and configure changes for tracetool.py
>>> simpletrace-v2: Handle variable number/size of elements per trace
>>> record.
>>> simpletrace.py: updated log reader script to handle new log format
>>>
>>> Makefile.objs | 6 +-
>>> Makefile.target | 10 +-
>>> configure | 4 +-
>>> monitor.c | 2 +-
>>> scripts/simpletrace.py | 110 ++++++++++-
>>> scripts/tracetool.py | 505
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> trace/simple.c | 178 ++++++-----------
>>> trace/simple.h | 31 +++-
>>> 8 files changed, 702 insertions(+), 144 deletions(-)
>>> create mode 100755 scripts/tracetool.py
>>>
>>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
