Re: [Qemu-devel] [RFC PATCH v2 0/7] QEMU binary instrumentation prototype

["Alex Bennée" <alex.bennee@linaro.org>]

Peter Maydell <peter.maydell@linaro.org> writes:

<snip>
>> Now I can see arguments against it from an interface complexity point of
>> view but I think plugins should get access to the TCG functions so they
>> can generate their own op sequences if need be and not have to call a
>> helper at all if they don't need to.
>
> I strongly disagree -- plugins should not have access to details
> of QEMU internals that might change from version to version, and
> definitely not access to generating their own TCG code.

The problem is I think a simple single helper with a PC and a CPU env is
fairly inflexible and inefficient. It would also make the API simpler if
we could leave the decision about installing the helper to the
instrumentation function. However I take your point that exposing the
whole TCG API might be a bit too much. Perhaps the qmeulib functions
could wrap enough so we could have an instrumentation function like
this:

  void plugins_instrument_before_insn(target_ulong disas_pc)
  {
      TCGv t_pc = qemulib_make_const(pc);
      qemulib_call_helper1(pc);
  }

By marshalling through qemulib we could keep track of temps allocated
and do the clean-up for the plugin or take the approach that plugin
writers need to have some idea of what they are doing.

In terms of the wider problem about exposing internals that might change
from version to version I wonder if we should care? Is the plugin API
one where we should provide ABI stability or should we take the approach
that Linux does and say if your code lives out-of-tree then it's your
problem to keep up if/when we change.

--
Alex Bennée