aboutsummaryrefslogtreecommitdiff
path: root/tracetool
AgeCommit message (Collapse)AuthorFilesLines
2010-11-21Add support for generating a systemtap tapset static probesDaniel P. Berrange1-17/+111
This introduces generation of a qemu.stp/qemu-system-XXX.stp files which provides tapsets with friendly names for static probes & their arguments. Instead of probe process("qemu").mark("qemu_malloc") { printf("Malloc %d %p\n", $arg1, $arg2); } It is now possible todo probe qemu.system.i386.qemu_malloc { printf("Malloc %d %p\n", size, ptr); } There is one tapset defined per target arch, for both user and system emulators. * Makefile.target: Generate stp files for each target * tracetool: Support for generating systemtap tapsets * configure: Check for whether systemtap is available with the DTrace backend Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-11-21Add a DTrace tracing backend targetted for SystemTAP compatabilityDaniel P. Berrange1-10/+112
This introduces a new tracing backend that targets the SystemTAP implementation of DTrace userspace tracing. The core functionality should be applicable and standard across any DTrace implementation on Solaris, OS-X, *BSD, but the Makefile rules will likely need some small additional changes to cope with OS specific build requirements. This backend builds a little differently from the other tracing backends. Specifically there is no 'trace.c' file, because the 'dtrace' command line tool generates a '.o' file directly from the dtrace probe definition file. The probe definition is usually named with a '.d' extension but QEMU uses '.d' files for its external makefile dependancy tracking, so this uses '.dtrace' as the extension for the probe definition file. The 'tracetool' program gains the ability to generate a trace.h file for DTrace, and also to generate the trace.d file containing the dtrace probe definition. Example usage of a dtrace probe in systemtap looks like: probe process("qemu").mark("qemu_malloc") { printf("Malloc %d %p\n", $arg1, $arg2); } * .gitignore: Ignore trace-dtrace.* * Makefile: Extra rules for generating DTrace files * Makefile.obj: Don't build trace.o for DTrace, use trace-dtrace.o generated by 'dtrace' instead * tracetool: Support for generating DTrace data files Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-11-21Revert "Add a DTrace tracing backend targetted for SystemTAP compatability"Anthony Liguori1-106/+10
This reverts commit 4addb1127f6327c7ebcbd150a6b589e7677adc92.
2010-11-21Revert "Add support for generating a systemtap tapset static probes"Anthony Liguori1-92/+0
This reverts commit 2834c3e0140c3b0ed4422909dfa0607b7213d95d. Conflicts: Makefile.target
2010-11-16Add support for generating a systemtap tapset static probesDaniel P. Berrange1-0/+92
This introduces generation of a qemu.stp/qemu-system-XXX.stp files which provides tapsets with friendly names for static probes & their arguments. Instead of probe process("qemu").mark("qemu_malloc") { printf("Malloc %d %p\n", $arg1, $arg2); } It is now possible todo probe qemu.system.i386.qemu_malloc { printf("Malloc %d %p\n", size, ptr); } There is one tapset defined per target arch. * Makefile: Generate a qemu.stp file for systemtap * tracetool: Support for generating systemtap tapsets Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-11-16Add a DTrace tracing backend targetted for SystemTAP compatabilityDaniel P. Berrange1-10/+106
This introduces a new tracing backend that targets the SystemTAP implementation of DTrace userspace tracing. The core functionality should be applicable and standard across any DTrace implementation on Solaris, OS-X, *BSD, but the Makefile rules will likely need some small additional changes to cope with OS specific build requirements. This backend builds a little differently from the other tracing backends. Specifically there is no 'trace.c' file, because the 'dtrace' command line tool generates a '.o' file directly from the dtrace probe definition file. The probe definition is usually named with a '.d' extension but QEMU uses '.d' files for its external makefile dependancy tracking, so this uses '.dtrace' as the extension for the probe definition file. The 'tracetool' program gains the ability to generate a trace.h file for DTrace, and also to generate the trace.d file containing the dtrace probe definition. Example usage of a dtrace probe in systemtap looks like: probe process("qemu").mark("qemu_malloc") { printf("Malloc %d %p\n", $arg1, $arg2); } * .gitignore: Ignore trace-dtrace.* * Makefile: Extra rules for generating DTrace files * Makefile.obj: Don't build trace.o for DTrace, use trace-dtrace.o generated by 'dtrace' instead * tracetool: Support for generating DTrace data files Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-10-09trace: Use TP_PROTO() and TP_ARGS() for LTTng USTStefan Hajnoczi1-1/+1
The LTTng UserSpace Tracer formerly used TPPROTO() and TPARGS() instead of TP_PROTO() and TP_ARGS() like the kernel uses. This has been changed so QEMU needs to follow. I am not aware of a graceful way of making the transition but since no one complained that the UST build is broken, it should be fine to just switch over without compatibility for old UST headers. The newer UST headers are shipping in distro packages so it is realistic to make this change now. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2010-10-09trace: Don't strip lines containing '#' arbitrarilyStefan Hajnoczi1-2/+1
Although comment lines must be skipped, the '#' character can occur in valid format strings. Be more careful when checking for comments. Leave comments at the end of the line where they will not interfere with other processing. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2010-09-11trace: fix a regex portability problemBlue Swirl1-1/+1
The /bin/sh in Milax has problems with the regex: Error: invalid trace backend Please choose a supported trace backend. Fix it by escaping ')' like the regexes with '('. Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2010-09-09trace: Add LTTng Userspace Tracer backendStefan Hajnoczi1-2/+83
This patch adds LTTng Userspace Tracer (UST) backend support. The UST system requires no kernel support but libust and liburcu must be installed. $ ./configure --trace-backend ust $ make Start the UST daemon: $ ustd & List available tracepoints and enable some: $ ustctl --list-markers $(pgrep qemu) [...] {PID: 5458, channel/marker: ust/paio_submit, state: 0, fmt: "acb %p opaque %p sector_num %lu nb_sectors %lu type %lu" 0x4b32ba} $ ustctl --enable-marker "ust/paio_submit" $(pgrep qemu) Run the trace: $ ustctl --create-trace $(pgrep qemu) $ ustctl --start-trace $(pgrep qemu) [...] $ ustctl --stop-trace $(pgrep qemu) $ ustctl --destroy-trace $(pgrep qemu) Trace results can be viewed using lttv-gui. More information about UST: http://lttng.org/ust Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> trace: Check for LTTng Userspace Tracer headers When using the 'ust' backend, check if the relevant headers are available at host. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-09-09trace: Support disabled events in trace-eventsStefan Hajnoczi1-5/+39
Sometimes it is useful to disable a trace event. Removing the event from trace-events is not enough since source code will call the trace_*() function for the event. This patch makes it easy to build without specific trace events by marking them disabled in trace-events: disable multiwrite_cb(void *mcb, int ret) "mcb %p ret %d" This builds without the multiwrite_cb trace event. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> trace: Allow bulk enabling/disabling of trace events at compile time For 'simple' trace backend, allow bulk enabling/disabling of trace events at compile time. Trace events that are preceded by 'disable' keyword are compiled in, but turned off by default. These can individually be turned on using the monitor. All other trace events are enabled by default. TODO : This could be enhanced when the trace-event namespace is partitioned into a group and an ID within that group. In such a case, marking a group as enabled would automatically enable all trace-events listed under it. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-09-09trace: Support for dynamically enabling/disabling trace eventsPrerna Saxena1-4/+20
This patch adds support for dynamically enabling/disabling of trace events. This is done by internally maintaining each trace event's state, and permitting logging of data from a trace event only if it is in an 'active' state. Monitor commands added : 1) info trace-events : to view all available trace events and their state. 2) trace-event NAME on|off : to enable/disable data logging from a given trace event. Eg, trace-event paio_submit off disables logging of data when paio_submit is hit. By default, all trace-events are disabled. One can enable desired trace-events via the monitor. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> trace: Monitor command 'info trace' Monitor command 'info trace' to display contents of trace buffer Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> trace: Remove monitor.h dependency from simpletrace User-mode targets don't have a monitor so the simple trace backend currently does not build on those targets. This patch abstracts the monitor printing interface so there is no direct coupling between simpletrace and the monitor. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-09-09trace: Add simple built-in tracing backendStefan Hajnoczi1-3/+75
This patch adds a simple tracer which produces binary trace files. To try out the simple backend: $ ./configure --trace-backend=simple $ make After running QEMU you can pretty-print the trace: $ ./simpletrace.py trace-events trace.log The output of simpletrace.py looks like this: qemu_realloc 0.699 ptr=0x24363f0 size=0x3 newptr=0x24363f0 qemu_free 0.768 ptr=0x24363f0 ^ ^---- timestamp delta (us) |____ trace event name Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> trace: Make trace record fields 64-bit Explicitly use 64-bit fields in trace records so that timestamps and magic numbers work for 32-bit host builds. Includes fixes from Prerna Saxena <prerna@linux.vnet.ibm.com>. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-09-09trace: Add trace-events file for declaring trace eventsStefan Hajnoczi1-0/+175
This patch introduces the trace-events file where trace events can be declared like so: qemu_malloc(size_t size) "size %zu" qemu_free(void *ptr) "ptr %p" These trace event declarations are processed by a new tool called tracetool to generate code for the trace events. Trace event declarations are independent of the backend tracing system (LTTng User Space Tracing, ftrace markers, DTrace). The default "nop" backend generates empty trace event functions. Therefore trace events are disabled by default. The trace-events file serves two purposes: 1. Adding trace events is easy. It is not necessary to understand the details of a backend tracing system. The trace-events file is a single location where trace events can be declared without code duplication. 2. QEMU is not tightly coupled to one particular backend tracing system. In order to support tracing across QEMU host platforms and to anticipate new backend tracing systems that are currently maturing, it is important to be flexible and not tied to one system. This commit includes fixes from Prerna Saxena <prerna@linux.vnet.ibm.com> and Blue Swirl <blauwirbel@gmail.com>. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>