[lttng-dev] [RFC PATCH v2 0/4] simpletrace : support var num of args and strings.
Mathieu Desnoyers
compudj at krystal.dyndns.org
Tue Jan 10 02:17:01 EST 2012
* Harsh Bora (harsh at linux.vnet.ibm.com) wrote:
> On 01/10/2012 05:44 AM, Mathieu Desnoyers wrote:
>> * Harsh Bora (harsh at linux.vnet.ibm.com) wrote:
>>> On 01/09/2012 09:31 PM, Mathieu Desnoyers wrote:
>>>> * Harsh Prateek Bora (harsh at 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 at 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);
>>
>
> I had tried with _NOARGS variants initially by manually changing the
> auto-generated code like this:
>
> In trace.h:
>
> DECLARE_TRACE_NOARGS(ust_slavio_misc_update_irq_raise);
> #define trace_slavio_misc_update_irq_raise
> trace_ust_slavio_misc_update_irq_raise
>
> In trace.c:
>
> DEFINE_TRACE_NOARGS(ust_slavio_misc_update_irq_raise);
>
> static void ust_slavio_misc_update_irq_raise_probe()
> {
> trace_mark(ust, slavio_misc_update_irq_raise);
> }
>
>
> However, it still gave error like this:
>
> [harsh at harshbora v9fs]$ make
> CC osdep.o
> cc1: warnings being treated as errors
> In file included from osdep.c:49:
> trace.h:277: error: data definition has no type or storage class
> trace.h:277: error: type defaults to ‘int’ in declaration of
> ‘DECLARE_TRACE_NOARGS’
> trace.h:277: error: parameter names (without types) in function declaration
>
>
> It will be great if you can provide a sample code (to be auto-generated)
> required for a trace-event with void argument.
Ah, right, now I remember that I only left DEFINE_TRACE and DECLARE_TRACE
as backward compatibility in UST 0.x, and did only add the "_NOARGS" to
the backward compatibility macros with an added underscore prefix.
If you really just want to have compatibility with UST 0.16, changing the
minimum of things compared with what you currently have, I would
recommend to use:
in trace.h:
_DECLARE_TRACEPOINT_NOARGS(ust_slavio_misc_update_irq_raise)
#define trace_slavio_misc_update_irq_raise trace_ust_slavio_misc_update_irq_raise
in trace.c:
DEFINE_TRACE(ust_slavio_misc_update_irq_raise);
static void ust_slavio_misc_update_irq_raise_probe(void)
{
trace_mark(ust, slavio_misc_update_irq_raise, UST_MARKER_NOARGS);
}
Let me know how this works for you,
Best regards,
Mathieu
>
> - Harsh
>
>>> 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.
>
> Thanks for the info, I will look into it later.
>>
>> 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
>>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list