On Tue, Jun 01, 2021 at 12:18:58PM +0100, Alex Bennée wrote:
> > +    if (tracefile) {
> > +        g_mutex_lock(&fmtx);
> > +        g_autoptr(GString) rep = g_string_new("");
> > +        bool is_store = qemu_plugin_mem_is_store(info);
> > +        g_string_append_printf(rep, "%c: 0x%" PRIx64,
> > +                is_store ? 'S' : 'L', effective_addr);
> > +        fprintf(tracefile, "%s\n", rep->str);
> > +        g_mutex_unlock(&fmtx);
> > +    }
> 
> I can see this would be useful for debugging but I'm wary of adding
> ad-hoc tracing formats when QEMU already has support for a wide range of
> tracing formats. We discussed this a bit in:
> 
>   Subject: trace_FOO_tcg bit-rotted?
>   Date: Tue, 06 Apr 2021 17:00:20 +0100
>   Message-ID: <87eefnwd0l.fsf@linaro.org>
> 
> However I don't know how easy it would be to leverage the existing
> tracing infrastructure from inside a plugin. As I understand it QEMU
> currently builds a static list of trace points during the build so maybe
> we would need additional infrastructure for a plugin to register a trace
> point and for the final output to be use-able. For example the binary
> trace output I think still needs to reference the source trace-events
> file?
> 
> So that's not a NACK but maybe we could spend a little time working out
> if we can come up with a cleaner solution?
> 
> Stefan, any thoughts?

QEMU's tracing system requires knowledge of all trace events at QEMU
compilation time. If the plugins are built together with QEMU then it
should be possible to give them their own trace-events files.

If not then I'm afraid it would be tricky to integrate into QEMU's
tracing system.

Stefan