[ltt-dev] [RFC] New UST 2.0 Tracepoint Event API : TRACEPOINT_FORMAT

[mathieu.desnoyers@efficios.com (Mathieu Desnoyers)]

Hi Brian,

* Cruickshank, Brian (bcruickshank at ti.com) wrote:
> Hi Mathieu,
>    I think the addition of per-tracepoint format strings and the
>    addition of "loglevel" information to the tracepoint API would both
>    be very helpful as it will make it easier to migrate from and
>    integrate with many existing software instrumentation APIs.

Yep, agreed,

>    How would the %s format specifier in the format string be handled?
>    E.g. would its use be restricted to referencing constant strings
>    (i.e. where the field associated with the %s specifier would be
>    logged as an integer value containing the address of the string,
>    which the host-side software would be able to use to look up the
>    text associated with the string by reading the metadata or the ELF
>    file for the application) or is the intent to support dynamically
>    allocated strings of arbitrary length (e.g. by rendering the string
>    on the target before logging the event)?  

CTF at this point does not include any knowledge of the ELF binary
topology. For %s, my intent is to allow saving the strings into the
buffer with the following TRACEPOINT_EVENT TP_FIELDS() definitions:

   ctf_array()          (fixed-size array of arbitrary integer types)
   ctf_array_text()     (fixed-size array of arbitrary integer types,
                         with known text encoding)
   ctf_sequence()       (dynamically-sized sequence of arbitrary integer
                         types.)
   ctf_sequence_text()  (dynamically-sized sequence of arbitrary integer
                         types, with known text encoding.)
   ctf_string()         (variable-length string (made of 8-bit
                         integers), with known encoding, ending with \0)

Eventually, if we decide to extend CTF to allow a new type that would be
e.g. a reference to content within the ELF binary, then %s could
additionally be used to refer to fields of that type for the use-case
you describe. But as currently CTF does not support description of this
kind of type, so it would be rather premature to discuss its implication
on TRACEPOINT_FORMAT().

How does that sound ?

Thanks for your feedback!

Mathieu

> 
> Regards,
>    Brian Cruickshank
>    Texas Instruments
> 
> -----Original Message-----
> From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com] 
> Sent: Wednesday, August 31, 2011 12:37 PM
> To: ltt-dev at lists.casi.polymtl.ca; Nils Carlson
> Subject: [ltt-dev] [RFC] New UST 2.0 Tracepoint Event API : TRACEPOINT_FORMAT
> 
> Hi,
> 
> I've been informed that support for a per-tracepoint format string would
> be welcomed by many. I would prefer not to make formats strings a
> requirement, but rather an optional feature. I am considering the
> following API:
> 
> TRACEPOINT_FORMAT(tracepoint_name,
>         "text describing a format string with args like %s and also %d",
>         fieldname_1, fieldname_2)
> 
> where fieldname_* refer to the name of the fields declared in the
> tracepoint (NOT the tracepoint arguments!).
> 
> e.g.
> 
> TRACEPOINT_EVENT(ust_tests_hello_tptest,
>         TP_PROTO(int anint, long along, char *text)
>         TP_ARGS(anint, along, text)
>         TP_FIELDS(
>                 ctf_integer(int, intfield, anint)
>                 ctf_integer(long, longfield, along)
>                 ctf_string(stringfield, text)
>         )
> )
> 
> TRACEPOINT_FORMAT(tracepoint_name,
>         "some message %d and more %s",
>         intfield, stringfield)
> 
> Having some level of automated compiler-level type checking for the
> format string in there might be a nice to have, but might be rather
> tricky, and could change the API slightly as I proceed to the
> implementation.
> 
> Thoughts ?
> 
> Thanks,
> 
> Mathieu
> 
> 
> -- 
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com