From: Lluís <xscript@gmx.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [RFC][PATCH v1 0/3] trace-instrument: let the user wrap/override code generated from trace-events
Date: Wed, 03 Nov 2010 20:58:14 +0100 [thread overview]
Message-ID: <20101103195814.6430.3786.stgit@ginnungagap.bsc.es> (raw)
Adds a new optional keyword ("instrument") to the syntax in "trace-events". When
specified, this event property lets the user provide her own implementation for
that tracing event.
Still, in case the user only wants to wrap around the tracing event, tracetool's
original implementation is accessible through function 'trace_##name##_backend',
instead of the original 'trace_##name' (which now the user has to provide).
The user-provided tracing functions are expected to be in the static library
"libinstrument.a", identified by the "--with-instrument" configuration
parameter.
TODO:
* Having the 'simple' backend generate code even when the "disable" property is
present, complicates the flow in 'tracetool'.
Is this behaviour really needed?
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
---
Lluís Vilanova (3):
trace: rewrite 'tracetool' to facilitate future extensions
trace-instrument: let the user override events generated by 'tracetool'
trace-instrument: handle config-time activation
Makefile | 4 -
Makefile.target | 29 ++++-
configure | 30 +++++
simpletrace.py | 2
trace-events | 23 +++-
tracetool | 336 +++++++++++++++++++++++++++++++++++--------------------
6 files changed, 289 insertions(+), 135 deletions(-)
next reply other threads:[~2010-11-03 19:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-03 19:58 Lluís [this message]
2010-11-03 19:58 ` [Qemu-devel] [PATCH v1 1/3] trace: rewrite 'tracetool' to facilitate future extensions Lluís
2010-11-03 19:58 ` [Qemu-devel] [PATCH v1 2/3] trace-instrument: let the user override events generated by 'tracetool' Lluís
2010-11-03 19:58 ` [Qemu-devel] [PATCH v1 3/3] trace-instrument: handle config-time activation Lluís
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101103195814.6430.3786.stgit@ginnungagap.bsc.es \
--to=xscript@gmx.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).