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

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

[Mathieu Desnoyers]

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] [RFC] New UST 2.0 Tracepoint Event API : TRACEPOINT_FORMAT

[Cruickshank, Brian]

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.  

   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)?  

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

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

[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