On Mon, Oct 25, 2010 at 11:13 AM, Lluís <xscr...@gmx.net> wrote:
> Blue Swirl writes:
>
>> On Fri, Oct 22, 2010 at 6:32 PM, Lluís <xscr...@gmx.net> wrote:
>>> instrument: Handle config-time activation
>>> instrument: Add initial instrumentation example
>>> instrument: Dynamic per-CPU state of static instrumentation points
>>> instrument: Code-generation macros
>>> instrument: [all] Include instrumentation helper declarations
>>> instrument: Add FETCH point
>>> instrument: [i386] Call FETCH point
>>> instrument: Add VMEM point
>>> instrument: [all] Call VMEM point
>>> instrument: Add PLVL point
>>> instrument: [i386] Call PLVL point
>
>> At least in these examples, the instrumentation code just prints out a
>> few interesting fields, so they are almost identical to tracepoints.
>
> Right, but that's because that is the simplest usage example I could
> think of.
>
>
>> The general approach seems to be that when an interesting event
>> happens, call the instrumentation code directly.
>
> That's the idea, so that one can go from calling tracing routines to
> providing hand-crafted code generators.
>
>
>> A lot of internal state needs to be made available to the
>> instrumentation code, which is a problem if that is considered as an
>> API.
>
> I don't get what you mean by that. In principle, only the macro
> arguments and the cpu instrumentation state are used.
I was referring to instr_disas, cpu_single_env hacks.
> I tried using static inlined functions on a first draft, but
> "instrument-host.h" is included on too many places and not every
> argument type was available at the include point. Maybe I could try to
> work this out again, such that routines are more self, contained, but
> there's still the problem of CPUState poisoning.
>
>
>> Perhaps this could be changed so that when the event happens, the only
>> effect is that the VM is stopped with some kind of notification. Then
>> a controlling application (external to QEMU) can inspect the state and
>> enable/disable tracepoints as it wishes, but using only the tools that
>> are available for tracepoints, QMP or GDB. Performance would be much
>> lower, though.
>
> Hmmm... as I see it, if tracing provided a two-level backend, I could
> work this out.
>
> I mean, for me, trace-points are just user-definable macros, I could
> provide instrumentation points through that, such that trace.h can
> include (if directed to do it) an extra user-provided header. Then,
> trace.h could look like:
>
> #include "qemu-common.h"
>
> #include "trace-override.h" // user defines trace_whatever
>
> #ifndef trace_whatever
> // maybe provide a separate trace-events-override file and do not
> // generate this with tracetool from trace-events
> static inline void trace_whatever(args...)
> {
> call trace backend
> }
> #endif
I had a pretty similar concept in mind when I suggested that
tracepoints could be extended, the syntax for trace-events could
become from:
disable apic_set_irq(int apic_irq_delivered) "coalescing %d"
to something like:
disable apic_set_irq(int apic_irq_delivered) "coalescing %d"
apic_irq_instr(void)
> Of course, instrumentation points found during code generation still
> need a different treatment even if they are to be used as plain
> trace-points, as they're not called at run-time unless you generate a
> call to a helper, so maybe a new trace-point type should be handled on
> 'tracetool' (like trace_generate_<whatever> or something like that),
> that generates a call to the tracing backend instead of simply calling
> it.
>
> This way, trace generation from these points can be neatly integrated
> with all the other tracing points.
Maybe the tracepoints should be separate from these helpers (which may
or may not have tracepoints).
