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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

> 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.