babeltrace | sink.ctf.fs escaping of struct member names

[MOESSBAUER, Felix]

On Thu, 2025-12-04 at 10:15 -0500, Philippe Proulx wrote:
> On Thu, Dec 4, 2025 at 5:10 AM MOESSBAUER, Felix via lttng-dev
> <lttng-dev at lists.lttng.org> wrote:
> > 
> > In my opinion, the escaping of the struct member names in the CTF
> > writer is not correct according to the CTF 1.8.3 spec: Section 4.2.1
> > states, that reserved keywords must not be used and the recommended
> > escaping is a underscore prefix. However, the spec does not state any
> > other names that need to be escaped and by that also not names starting
> > with an underscore itself.
> > 
> > IOW: The CTF writer currently unconditionally escapes all struct member
> > names, which I assume to be incorrect
> 
> It's not incorrect per se.
> 
> Underscore as a member name escaping mechanism has always been a
> nightmare in CTF 1.8. For example, given:
> 
>     uint8 _len;
>     string _strings[length here];
> 
> Should we use `_len` or `len`? And what about this:
> 
>     struct {
>         uint8 meow;
>         uint8 _meow;
>     } _mix;

Okay... that's the reason. Thanks for the example.

> 
> LTTng chooses to escape everything with `_`, except the packet header,
> packet context, and event record header names it knows. We did exactly
> the same in `sink.ctf.fs`.
> 
> CTF 1.8 doesn't specify `cpu_id` by the way; it's an LTTngism.

Well... This is a more generic question if it is really the job of the
serializer to fix possible name clashes in the output. Anyways,
unfortunately LTTng uses this field and does not allow escaping.

> 
> CTF 2 solves all of that!

I would love to switch to CTF2, however we need support for it in
trace-compass, which AFAIK is not even implemented yet.

> 
> Since CTF 1.8 is pretty much deprecated at this point, I want to invest
> as little time as possible in anything related to this legacy format,
> whatever the project. Just make it work considering the known use cases.
> 
> Therefore, for your specific problem, I suggest that you specifically
> avoid the "protection" (escaping) for `cpu_id` in the packet context
> field class _only for LTTng traces_. It should be good enough and make
> Trace Compass work. Trace Compass could also unescape packet context
> member names, but it will be faster to do this in Babeltrace 2 and it
> will match the LTTng behaviour more closely.

This is tricky, as we don't really know if the trace is an LTTng trace
or not. However, we can hide it behind the proposed create-lttng-index
flag, as it is anyways only needed in combination with an index (I
still don't know why, but ok...).

> 
> > 
> > I tried fixing this with the attached patch,
> 
> If you need comments on a patch, even if it's an RFC, please prefer
> Gerrit so that we can comment specific lines and follow the discussion
> more easily.

Ok, got it. I'll add the new implementation to the create-lttng-index
series (as it anyways depends on this).

Best regards,
Felix

> 
> BR,
> 
> Philippe

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany