Re: [Qemu-devel] [PATCH 00/13] instrument: Add basic event instrumentation

[Lluís Vilanova]

Peter Maydell writes:

> On 25 July 2017 at 14:19, Stefan Hajnoczi <address@hidden> wrote:
>> Instead I suggest adding a trace backend generates calls to registered
>> "callback" functions:
>> 
>> $ cat >my-instrumentation.c
>> #include "trace/control.h"
>> 
>> static void my_cpu_in(unsigned int addr, char size, unsigned int val)
>> {
>> printf("my_cpu_in\n");
>> }
>> 
>> static void my_init(void)
>> {
>> trace_register_event_callback("cpu_in", my_cpu_in);
>> trace_enable_events("cpu_in");
>> }
>> trace_init(my_init);
>> 
>> $ ./configure --enable-trace-backends=log,callback && make -j4
>> 
>> This is still a clean interface that allows instrumentation code to be
>> kept separate from the trace event call sites.
>> 
>> The instrumentation code gets compiled into QEMU, but that shouldn't be
>> a huge burden since QEMU's Makefiles only recompile changed source
>> files (only the first build is slow).

> Is your proposal that my-instrumentation.c gets compiled into
> QEMU at this point? That doesn't seem like a great idea to
> me, because it means you can only use this tracing if you
> build QEMU yourself, and distros won't enable it and so
> lots of our users won't have convenient access to it.
> I'd much rather see a cleanly designed plugin interface
> (which we should be able to implement in a manner that doesn't
> let the plugin monkey patch arbitrary parts of QEMU beyond
> what can already be achieved via LD_PRELOAD).

Just to be clear, what do you both mean by monkey-patching?

* Accessing unintended symbols in QEMU from the library (and from there
  modifying QEMU's behavior).
* QEMU using symbols on the library instead of its own just because they have
  the same name.

As I said, the former can be accomplished by compiling QEMU with
"-fvisibility=hidden".

The latter is already achieved by using dlopen with RTLD_LOCAL (the default).


Cheers,
  Lluis