Re: libtraceevent | API clarifications needed

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 3 Dec 2025 11:20:34 +0000
"MOESSBAUER, Felix" <felix.moessbauer@siemens.com> wrote:

> > First I'll say that I absolutely hate the libtraceevent interface.
> > Unfortunately, it was ported over to perf before it was "sanitized". But oh
> > well, I have to live with it. I would love to come up with a new interface
> > that would make all this easier.  
> 
> No need for excuses. The library is great and tremendously simplifies
> working with trace events. Thank you!

Not an excuse. I curse the API all the time ;-)

I wrote it, but I still need to reference the man pages to figure out how
to use it. If the author can't use their own API without referencing a
manual, that's a sure sign that the API sucks!


> > If tep->file_bigendian != tep_is_bigendian() then a swap is needed.  
> 
> Ok, but I just found the tep_read_number() interface which I'm now
> using as following:
> 
> data_raw=tep_get_field_raw(NULL, trace_event, field->name, rec, &len,
> 0);
> item_size=len / field->arraylen;
> val=tep_read_number(field->event->tep, &data_raw[i * item_size], len);
> 
> This should also do the job, as tep_read_number() takes care of the
> endianess handling.

Great!


> > > 
> > > symbolic fields
> > > 
> > > How to get the symbolic representation of fields that are marked
> > > TEP_FIELD_IS_SYMBOLIC (example: softirq_entry->vec)? I tried
> > > tep_print_field_content, but this converts the data to a string integer
> > > instead of the symbolic representation (e.g. I get a "0" instead of a 
> > > "HI").  
> > 
> > This is something I even wanted, but there's not really a good way to do
> > it. Although, I wanted a generic way, but if a field is marked symbolic, we
> > could use that. That is, we would need to parse the print_fmt array itself,
> > and find the:
> > 
> >  "__print_symbolic(REC->vec, { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" }, { 5, "IRQ_POLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" }, { 9, "RCU" })"
> > 
> > That is, look for the "__print_symbolic(REC->[FIELD-NAME], ..." and parse that.  
> 
> The trace-cmd report seems to be able to symbolize this, as well as
> symbolizing instruction pointers (e.g. the caller field of the ftrace
> kernel_stack). Not that I currently need this, but I'm wondering how
> trace-cmd is able to do this. Probably need to check the sources.
> 

Probably due to plugins. Run: trace-cmd report -N

If it still shows things properly, then it did do something special.
Otherwise a plugin took over. They are in libtraceevent, in the plugins
directory. There are several plugins that override how an event is read and
it does the work manually.

-- Steve