Re: [PATCH RFC 0/5] rust: implement tracing

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

Hello Paolo,

On Wed, Aug 6, 2025 at 12:03 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 8/5/25 22:06, Manos Pitsidianakis wrote:
> >> If you're thinking this is all rather complicated, you'd be right,
> >> which is why for initial feature parity I figured the simplest is
> >> likely to just wrap the existing QEMU inline probe function, so
> >> Rust doesn't need to know about the different backends... yet...
>
> It's not too hard to add individual backends (other than dtrace---see
> below--and ust which doesn't build for me(*) and I wanted to deprecate).
>   Tanish is pretty close to being able to post initial work.

Ack, I look forward to it :) I hope my RFC provides them some
inspiration on what things (not) to do.

Thanks,

>
> > Yes, that indeed makes sense.  Generated C trace headers statically
> > linked to a standalone trace crate library for each subsystem, that
> > rust qemu crates can link to in return is the cleanest solution for
> > this approach IMHO, because doing this kind of codegen via macros
> > needs interaction with meson to generate the C sources and then run
> > bindgen all while compiling this one crate which is a single meson lib
> > target.
> >
> > It might be possible to generate the equivalent of the C code for each
> > backend just like this RFC generates only the log backend code, I'll
> > take a look out of curiosity...
> >
> >> FWIW, the original DTrace authors created a Rust crate with native
> >> rust integration of dynamic probes.
> >>
> >>    https://github.com/oxidecomputer/usdt
> >>
> >> I think that (somehow) we probably want to integrate that with QEMU
> >> and its tracetool.
>
> This unfortunately only works for macOS and Solaris.  It also has quite
> a few dependencies (~25) on other crates.  There is also a "probe" crate
> (https://github.com/cuviper/probe-rs) that is minimal and (currently)
> specific to Linux, which is what I planned to use.
>
> By the way, while I like the idea of using Rust format strings, there
> are parts of tracetool (e.g. format/log_stap.py) that need the printf
> strings, and also backends (e.g. backend/syslog.py) that call into libc
> and therefore need to use printf format strings.  So I think we're stuck.
>
> Paolo
>
> (*) that's because this tracepoint:
>
> visit_type_str(void *v, const char *name, char **obj) "v=%p name=%s obj=%p
>
> incorrectly handles 'char **' as a string.  The breakage has been there
> since 2016, though probably it's only more recent versions of ust that
> actually fail to compile and until then the bug was latent until you
> enabled this tracepoint.  But it seems unlikely that anyone has used the
> ust backend recently.
>

-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd