Commit Graph

132 Commits

Author SHA1 Message Date
Roman Bolshakov
5e7477bc82 scripts/tracetool: Use void pointer for vcpu
dtrace on macOS complains that CPUState * is used for a few probes:

  dtrace: failed to compile script trace-dtrace-root.dtrace: line 130: syntax error near "CPUState"

A comment in scripts/tracetool/__init__.py mentions that:

  We only want to allow standard C types or fixed sized
  integer types. We don't want QEMU specific types
  as we can't assume trace backends can resolve all the
  typedefs

Fixes: 3d211d9f4d ("trace: Add 'vcpu' event property to trace guest vCPU")
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-id: 20200717093517.73397-3-r.bolshakov@yadro.com
Cc: Cameron Esfahani <dirty@apple.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-09 17:16:15 +01:00
Roman Bolshakov
0807162e60 scripts/tracetool: Fix dtrace generation for macOS
dtrace USDT is fully supported since OS X 10.6. There are a few
peculiarities compared to other dtrace flavors.

1. It doesn't accept empty files.
2. It doesn't recognize bool type but accepts C99 _Bool.
3. It converts int8_t * in probe points to char * in
   header files and introduces [-Wpointer-sign] warning.

Cc: Cameron Esfahani <dirty@apple.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20200717093517.73397-2-r.bolshakov@yadro.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-09 17:16:12 +01:00
Paolo Bonzini
a81df1b68b libqemuutil, qapi, trace: convert to meson
This shows how to do some "computations" in meson.build using its array
and dictionary data structures, and also a basic usage of the sourceset
module for conditional compilation.

Notice the new "if have_system" part of util/meson.build, which fixes
a bug in the old build system was buggy: util/dbus.c was built even for
non-softmmu builds, but the dependency on -lgio was lost when the linking
was done through libqemuutil.a.  Because all of its users required gio
otherwise, the bug was hidden.  Meson instead propagates libqemuutil's
dependencies down to its users, and shows the problem.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-21 06:30:08 -04:00
Paolo Bonzini
243af0225a trace: switch position of headers to what Meson requires
Meson doesn't enjoy the same flexibility we have with Make in choosing
the include path.  In particular the tracing headers are using
$(build_root)/$(<D).

In order to keep the include directives unchanged,
the simplest solution is to generate headers with patterns like
"trace/trace-audio.h" and place forwarding headers in the source tree
such that for example "audio/trace.h" includes "trace/trace-audio.h".

This patch is too ugly to be applied to the Makefiles now.  It's only
a way to separate the changes to the tracing header files from the
Meson rewrite of the tracing logic.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-21 06:18:24 -04:00
Stefan Hajnoczi
000822441e tracetool: carefully define SDT_USE_VARIADIC
The dtrace backend defines SDT_USE_VARIADIC as a workaround for a
conflict with a LTTng UST header file, which requires SDT_USE_VARIADIC
to be defined.

LTTng UST <lttng/tracepoint.h> breaks if included after generated dtrace
headers because SDT_USE_VARIADIC will already be defined:

  #ifdef LTTNG_UST_HAVE_SDT_INTEGRATION
  #define SDT_USE_VARIADIC <-- error, it's already defined
  #include <sys/sdt.h>

Be more careful when defining SDT_USE_VARIADIC. This fixes the build
when both the dtrace and ust tracers are enabled at the same time.

Fixes: 27e08bab94 ("tracetool: work around ust <sys/sdt.h> include conflict")
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20200729153926.127083-1-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-07-30 16:02:38 +01:00
Stefan Hajnoczi
27e08bab94 tracetool: work around ust <sys/sdt.h> include conflict
Both the dtrace and ust backends may include <sys/sdt.h> but LTTng
Userspace Tracer 2.11 and later requires SDT_USE_VARIADIC to be defined
before including the header file.

This is a classic problem with C header files included from different
parts of a program. If the same header is included twice within the same
compilation unit then the first inclusion determines the macro
environment.

Work around this by defining SDT_USE_VARIADIC in the dtrace backend too.
It doesn't hurt and fixes a missing STAP_PROBEV() compiler error when
the ust backend is enabled together with the dtrace backend.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20200625140757.237012-1-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-07-07 16:07:14 +01:00
Philippe Mathieu-Daudé
f892b494fa scripts/tracetool: Update maintainer email address
There is an effort in progress to generate a QEMU Python
package. As I'm not sure this old email is still valid,
update it to not produce package with broken maintainer
email.

Patch created mechanically by running:

 $ sed -i 's,\(__email__ *= "\)stefanha@linux.vnet.ibm.com",\1stefanha@redhat.com",' \
         $(git grep -l 'email.*stefanha@linux.vnet.ibm.com')

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20200511082816.696-1-philmd@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-06-24 11:21:00 +01:00
Philippe Mathieu-Daudé
91aef87a2b scripts/tracetool: Remove shebang header
Patch created mechanically by running:

  $ chmod 644 $(git grep -lF '#!/usr/bin/env python' \
      | xargs grep -L 'if __name__.*__main__')
  $ sed -i "/^#\!\/usr\/bin\/\(env\ \)\?python.\?$/d" \
      $(git grep -lF '#!/usr/bin/env python' \
      | xargs grep -L 'if __name__.*__main__')

Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200130163232.10446-9-philmd@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-07 15:12:48 +01:00
Alex Bennée
504f73f7b3 trace: add mmu_index to mem_info
We are going to re-use mem_info later for plugins and will need to
track the mmu_idx for softmmu code.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2019-10-28 15:12:38 +00:00
Stefan Hajnoczi
403e11edbf trace: avoid "is" with a literal Python 3.8 warnings
The following statement produces a SyntaxWarning with Python 3.8:

  if len(format) is 0:
  scripts/tracetool/__init__.py:459: SyntaxWarning: "is" with a literal. Did you mean "=="?

Use the conventional len(x) == 0 syntax instead.

Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20191010122154.10553-1-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-10-15 09:47:16 +01:00
Philippe Mathieu-Daudé
9f7ad79c16 trace: Forbid event format ending with newline character
Event format ending with newlines confuse the trace reports.
Forbid them.

Add a check to refuse new format added with trailing newline:

  $ make
  [...]
    GEN     hw/misc/trace.h
  Traceback (most recent call last):
    File "scripts/tracetool.py", line 152, in <module>
      main(sys.argv)
    File "scripts/tracetool.py", line 143, in main
      events.extend(tracetool.read_events(fh, arg))
    File "scripts/tracetool/__init__.py", line 367, in read_events
      event = Event.build(line)
    File "scripts/tracetool/__init__.py", line 281, in build
      raise ValueError("Event format can not end with a newline character")
  ValueError: Error at hw/misc/trace-events:121: Event format can not end with a newline character

Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190916095121.29506-3-philmd@redhat.com
Message-Id: <20190916095121.29506-3-philmd@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-09-18 10:20:15 +01:00
Markus Armbruster
13d4ff07e8 trace: Do not include qom/cpu.h into generated trace.h
docs/devel/tracing.txt explains "since many source files include
trace.h, [the generated trace.h use] a minimum of types and other
header files included to keep the namespace clean and compile times
and dependencies down."

Commit 4815185902 "trace: Add per-vCPU tracing states for events with
the 'vcpu' property" made them all include qom/cpu.h via
control-internal.h.  qom/cpu.h in turn includes about thirty headers.
Ouch.

Per-vCPU tracing is currently not supported in sub-directories'
trace-events.  In other words, qom/cpu.h can only be used in
trace-root.h, not in any trace.h.

Split trace/control-vcpu.h off trace/control.h and
trace/control-internal.h.  Have the generated trace.h include
trace/control.h (which no longer includes qom/cpu.h), and trace-root.h
include trace/control-vcpu.h (which includes it).

The resulting improvement is a bit disappointing: in my "build
everything" tree, some 1100 out of 6600 objects (not counting tests
and objects that don't depend on qemu/osdep.h) depend on a trace.h,
and about 600 of them no longer depend on qom/cpu.h.  But more than
1300 others depend on trace-root.h.  More work is clearly needed.
Left for another day.

Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190812052359.30071-8-armbru@redhat.com>
2019-08-16 13:31:52 +02:00
Markus Armbruster
988fa10304 trace: Eliminate use of TARGET_FMT_plx
hw/tpm/trace-events uses TARGET_FMT_plx formats with uint64_t
arguments.  That's wrong, TARGET_FMT_plx takes hwaddr.  Since hwaddr
happens to be uint64_t, it works anyway.  Messed up in commit
ec427498da, v2.12.0.  Clean up by replacing TARGET_FMT_plx with its
macro expansion.

scripts/tracetool/format/log_stap.py (commit 62dd1048c0, v4.0.0) has
a special case for TARGET_FMT_plx.  Delete it.

Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20190812052359.30071-7-armbru@redhat.com>
2019-08-16 13:31:51 +02:00
Markus Armbruster
a8d2532645 Include qemu-common.h exactly where needed
No header includes qemu-common.h after this commit, as prescribed by
qemu-common.h's file comment.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190523143508.25387-5-armbru@redhat.com>
[Rebased with conflicts resolved automatically, except for
include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c
block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c
target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h
target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h
target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h
target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and
net/tap-bsd.c fixed up]
2019-06-12 13:20:20 +02:00
Richard Henderson
29a0af618d cpu: Replace ENV_GET_CPU with env_cpu
Now that we have both ArchCPU and CPUArchState, we can define
this generically instead of via macro in each target's cpu.h.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-06-10 07:03:34 -07:00
Stefan Hajnoczi
b33b890cd0 trace: avoid SystemTap dtrace(1) warnings on empty files
target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}".  SystemTap's
dtrace(1) tool prints a warning when processing this input file.

This patch avoids the error by emitting an empty file instead of
"provider qemu {}" when there are no enabled trace events.

Fixes: 23c3d569f4 ("target/hppa: add TLB trace events")
Reported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 20190321170831.6539-3-stefanha@redhat.com
Message-Id: <20190321170831.6539-3-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22 15:55:50 +00:00
Daniel P. Berrangé
62dd1048c0 trace: add ability to do simple printf logging via systemtap
The dtrace systemtap trace backend for QEMU is very powerful but it is
also somewhat unfriendly to users who aren't familiar with systemtap,
or who don't need its power right now.

  stap -e "....some strange script...."

The 'log' backend for QEMU by comparison is very crude but incredibly
easy to use:

 $ qemu -d trace:qio* ...some args...
 23266@1547735759.137292:qio_channel_socket_new Socket new ioc=0x563a8a39d400
 23266@1547735759.137305:qio_task_new Task new task=0x563a891d0570 source=0x563a8a39d400 func=0x563a86f1e6c0 opaque=0x563a89078000
 23266@1547735759.137326:qio_task_thread_start Task thread start task=0x563a891d0570 worker=0x563a86f1ce50 opaque=0x563a891d9d90
 23273@1547735759.137491:qio_task_thread_run Task thread run task=0x563a891d0570
 23273@1547735759.137503:qio_channel_socket_connect_sync Socket connect sync ioc=0x563a8a39d400 addr=0x563a891d9d90
 23273@1547735759.138108:qio_channel_socket_connect_fail Socket connect fail ioc=0x563a8a39d400

This commit introduces a way to do simple printf style logging of probe
points using systemtap. In particular it creates another set of tapsets,
one per emulator:

  /usr/share/systemtap/tapset/qemu-*-log.stp

These pre-define probe functions which simply call printf() on their
arguments. The printf() format string is taken from the normal
trace-events files, with a little munging to the format specifiers
to cope with systemtap's more restrictive syntax.

With this you can now do

 $ stap -e 'probe qemu.system.x86_64.log.qio*{}'
 22806@1547735341399856820 qio_channel_socket_new Socket new ioc=0x56135d1d7c00
 22806@1547735341399862570 qio_task_new Task new task=0x56135cd66eb0 source=0x56135d1d7c00 func=0x56135af746c0 opaque=0x56135bf06400
 22806@1547735341399865943 qio_task_thread_start Task thread start task=0x56135cd66eb0 worker=0x56135af72e50 opaque=0x56135c071d70
 22806@1547735341399976816 qio_task_thread_run Task thread run task=0x56135cd66eb0

We go one step further though and introduce a 'qemu-trace-stap' tool to
make this even easier

 $ qemu-trace-stap run qemu-system-x86_64 'qio*'
 22806@1547735341399856820 qio_channel_socket_new Socket new ioc=0x56135d1d7c00
 22806@1547735341399862570 qio_task_new Task new task=0x56135cd66eb0 source=0x56135d1d7c00 func=0x56135af746c0 opaque=0x56135bf06400
 22806@1547735341399865943 qio_task_thread_start Task thread start task=0x56135cd66eb0 worker=0x56135af72e50 opaque=0x56135c071d70
 22806@1547735341399976816 qio_task_thread_run Task thread run task=0x56135cd66eb0

This tool is clever in that it will automatically change the
SYSTEMTAP_TAPSET env variable to point to the directory containing the
right set of probes for the QEMU binary path you give it. This is useful
if you have QEMU installed in /usr but are trying to test and trace a
binary in /home/berrange/usr/qemu-git. In that case you'd do

 $ qemu-trace-stap run /home/berrange/usr/qemu-git/bin/qemu-system-x86_64 'qio*'

And it'll make sure /home/berrange/usr/qemu-git/share/systemtap/tapset
is used for the trace session

The 'qemu-trace-stap' script takes a verbose arg so you can understand
what it is running

 $ qemu-trace-stap run /home/berrange/usr/qemu-git/bin/qemu-system-x86_64 'qio*'
 Using tapset dir '/home/berrange/usr/qemu-git/share/systemtap/tapset' for binary '/home/berrange/usr/qemu-git/bin/qemu-system-x86_64'
 Compiling script 'probe qemu.system.x86_64.log.qio* {}'
 Running script, <Ctrl>-c to quit
 ...trace output...

It can enable multiple probes at once

 $ qemu-trace-stap run qemu-system-x86_64 'qio*' 'qcrypto*' 'buffer*'

By default it monitors all existing running processes and all future
launched proceses. This can be restricted to a specific PID using the
--pid arg

 $ qemu-trace-stap run --pid 2532 qemu-system-x86_64 'qio*'

Finally if you can't remember what probes are valid it can tell you

 $ qemu-trace-stap list qemu-system-x86_64
 ahci_check_irq
 ahci_cmd_done
 ahci_dma_prepare_buf
 ahci_dma_prepare_buf_fail
 ahci_dma_rw_buf
 ahci_irq_lower
 ...snip...

Or list just those matching a prefix pattern

 $ qemu-trace-stap list -v qemu-system-x86_64 'qio*'
 Using tapset dir '/home/berrange/usr/qemu-git/share/systemtap/tapset' for binary '/home/berrange/usr/qemu-git/bin/qemu-system-x86_64'
 Listing probes with name 'qemu.system.x86_64.log.qio*'
 qio_channel_command_abort
 qio_channel_command_new_pid
 qio_channel_command_new_spawn
 qio_channel_command_wait
 qio_channel_file_new_fd
 ...snip...

Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20190123120016.4538-5-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-01-24 14:16:56 +00:00
Daniel P. Berrangé
772f1b3721 trace: forbid use of %m in trace event format strings
The '%m' format instructs glibc's printf()/syslog() implementation to
insert the contents of strerror(errno). Since this is a glibc extension
it should generally be avoided in QEMU due to need for portability to a
variety of platforms.

Even though vfio is Linux-only code that could otherwise use "%m", it
must still be avoided in trace-events files because several of the
backends do not use the format string and so this error information is
invisible to them.

The errno string value should be given as an explicit trace argument
instead, making it accessible to all backends. This also allows it to
work correctly with future patches that use the format string with
systemtap's simple printf code.

Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20190123120016.4538-4-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-01-24 14:16:56 +00:00
Daniel P. Berrangé
7760636309 trace: enforce that every trace-events file has a final newline
When generating the trace-events-all file, the build system simply
concatenates all the individual trace-events files. If any one of those
files does not have a final newline, the printf format string will have
the contents of the first line of the next file appended to it, which is
usually a '#' comment.

Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20190123120016.4538-3-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-01-24 14:16:56 +00:00
Philippe Mathieu-Daudé
9ab5a24b52 scripts: Remove unused python imports
Reported-by: LGTM code review
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20181108143422.15955-1-philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-17 17:52:40 -02:00
Fabiano Rosas
8fbc12f324 tracetool: Include thread id information in log backend
Currently the log backend prints the process id of QEMU at the start
of each output line, but since threads share the same PID there is no
clear distinction between their outputs.

Having the thread id present in the log makes it easier to see when
output comes from different threads. E.g.:

12423@1538597569.672527:qemu_mutex_lock waiting on mutex 0x1103ee60 (/root/qemu/util/main-loop.c:236)
...
12430@1538597569.503928:qemu_mutex_unlock released mutex 0x1103ee60 (/root/qemu/cpus.c:1238)
12431@1538597569.503937:qemu_mutex_locked taken mutex 0x1103ee60 (/root/qemu/cpus.c:1257)
^here

In the above, 12423 is the main process id and 12430 & 12431 are the
two vcpu threads.

 (qemu) info cpus
 * CPU #0: thread_id=12430
   CPU #1: thread_id=12431

Suggested-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-12-12 10:04:59 +00:00
Philippe Mathieu-Daudé
82c4f87e0e trace: Fix format string for the struct timeval members casted to size_t
This fixes when using GCC with -Wformat-signedness:

    migration/trace.h: In function ‘_nocheck__trace_dirty_bitmap_load_success’:
    migration/trace.h:6368:24: error: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 3 has type ‘long unsigned int’ [-Werror=format=]
      qemu_log("%d@%zd.%06zd:dirty_bitmap_load_success " "" "\n",
                   ~~^
                   %ld
    migration/trace.h:6370:18:
               (size_t)_now.tv_sec, (size_t)_now.tv_usec
               ~~~~~~~~~~~~~~~~~~~
    migration/trace.h:6368:30: error: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 4 has type ‘long unsigned int’ [-Werror=format=]
      qemu_log("%d@%zd.%06zd:dirty_bitmap_load_success " "" "\n",
                       ~~~~^
                       %06ld
    migration/trace.h:6370:39:
               (size_t)_now.tv_sec, (size_t)_now.tv_usec
                                    ~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-06-29 15:04:18 +01:00
Stefan Hajnoczi
ec09f87753 trace: forbid floating point types
Only one existing trace event uses a floating point type.  Unfortunately
float and double cannot be supported since SystemTap does not have
floating point types.

Remove float and double from the whitelist and document this limitation.
Update the migrate_transferred trace event to use uint64_t instead of
double.

Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-id: 20180621150254.4922-1-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-06-27 11:09:29 +01:00
Daniel P. Berrangé
73ff061032 trace: only permit standard C types and fixed size integer types
Some trace backends will compile code based on the declared trace
events. It should not be assumed that the backends can resolve any QEMU
specific typedefs. So trace events should restrict their argument
types to the standard C types and fixed size integer types. Any complex
pointer types can be declared as "void *" for purposes of trace events,
since nothing will be dereferencing these pointer arguments.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20180308155524.5082-3-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-12 11:10:20 +00:00
Daniel P. Berrangé
86b5aacfb9 trace: include filename when printing parser error messages
Improves error messages from:

  ValueError: Error on line 72: need more than 1 value to unpack

To

  ValueError: Error at /home/berrange/src/virt/qemu/trace-events:72:
    need more than 1 value to unpack

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180306154650.24075-1-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-12 11:10:20 +00:00
Peter Maydell
be0aa7ac89 log-for-trace.h: Split out parts of log.h used by trace.h
A persistent build problem we see is where a source file
accidentally omits the #include of log.h. This slips through
local developer testing because if you configure with the
default (log) trace backend trace.h will pull in log.h for you.
Compilation fails only if some other backend is selected.

To make this error cause a compile failure regardless of
the configured trace backend, split out the parts of log.h
that trace.h requires into a new log-for-trace.h header.
Since almost all manual uses of the log.h functions will
use constants or functions which aren't in log-for-trace.h,
this will let us catch missing #include "qemu/log.h" more
consistently.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180213140029.8308-1-peter.maydell@linaro.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-12 11:10:20 +00:00
Jon Emil Jahren
61b01bbc6c tracetool: For ust trace bool type as ctf_integer
Previously functions having arguments of type bool was not traced
properly. The bool arguments were missing from the trace.

Signed-off-by: Jon Emil Jahren <jonemilj@gmail.com>
Message-id: 20180129041648.30884-3-jonemilj@gmail.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-02-19 13:09:44 +00:00
Jon Emil Jahren
fb1a66bc01 tracetool: Update argument format regex to non-greedy star
Using the greedy star matching, arguments like "...%"PRIx64 caused issues
for functions with multiple PRI formats.

The issue was only seen with the ust backend, as it is the only one
using the format regex.

The result for many functions was that the arguments coming after the
greedy star end was left out of the tracepoint, and in some cases some
of the arguments that was traced had the wrong format.

Signed-off-by: Jon Emil Jahren <jonemilj@gmail.com>
Message-id: 20180129041648.30884-2-jonemilj@gmail.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-02-19 13:09:44 +00:00
Stefan Hajnoczi
24f4d3d3ae tracetool: report error on foo() instead of foo(void)
C functions with no arguments must be declared foo(void) instead of
foo().  The tracetool argument list parser has never accepted an empty
argument list.  This patch adds a clear error message for this error
case.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180110202553.31889-4-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-01-29 10:34:55 +00:00
Stefan Hajnoczi
6e497fa1b1 tracetool: clarify that "formats" means "format strings"
The terminology used by tracetool is not consistent with C sprintf or
docs/devel/tracing.txt.  The word "formats" is sometimes used to mean
"format strings".

This patch clarifies comments and error messages that contain this word.

Note that the error message lines are longer than 80 characters but I
have not wrapped them to aid grepping.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180110202553.31889-3-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-01-29 10:34:55 +00:00
Stefan Hajnoczi
5069b56189 tracetool: prefix parse errors with line numbers
Include the file line number in the message that is printed when
trace-events parse errors are raised.

[Use enumerate(fobj, 1) to avoid having to increment a 0-based index
later, as suggested by Eric Blake.
--Stefan]

Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180110202553.31889-2-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-01-29 10:34:55 +00:00
Stefan Hajnoczi
d6b76d6805 trace: use static event ID mapping in simpletrace.stp
This is a partial revert of commit
7f1b588f20 ("trace: emit name <-> ID
mapping in simpletrace header"), which broke the SystemTap flight
recorder because event mapping records may not be present in the ring
buffer when the trace is analyzed.  This means simpletrace.py
--no-header does not know the event ID mapping needed to pretty-print
the trace.

Instead of numbering events dynamically, use a static event ID mapping
as dictated by the event order in the trace-events-all file.

The simpletrace.py script also uses trace-events-all so the next patch
will fix the simpletrace.py --no-header option to take advantage of this
knowledge.

Cc: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170815084430.7128-2-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-08-15 12:50:29 +01:00
Stefan Hajnoczi
3932ef3ffb trace: add TRACE_<event>_BACKEND_DSTATE()
QEMU keeps track of trace event enabled/disabled state and provides
monitor commands to inspect and modify the "dstate".  SystemTap and
LTTng UST maintain independent enabled/disabled states for each trace
event, the other backends rely on QEMU dstate.

Introduce a new per-event macro that combines backend-specific dstate
like this:

  #define TRACE_MY_EVENT_BACKEND_DSTATE() ( \
      QEMU_MY_EVENT_ENABLED() || /* SystemTap */ \
      tracepoint_enabled(qemu, my_event) /* LTTng UST */ || \
      false)

This will be used to extend trace_event_get_state() in the next patch.

[Daniel Berrange pointed out that QEMU_MY_EVENT_ENABLED() must be true
by default, not false.  This way events will fire even if the DTrace
implementation does not implement the SystemTap semaphores feature.

Ubuntu Precise uses lttng-ust-dev 2.0.2 which does not have
tracepoint_enabled(), so we need a compatibility wrapper to keep Travis
builds passing.
--Stefan]

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20170731140718.22010-2-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

fixup! trace: add TRACE_<event>_BACKEND_DSTATE()
2017-08-01 12:07:48 +01:00
Daniel P. Berrange
ea1ff54f7d trace: ensure unique function / variable names per .stp file
The simpletrace compatibility code for systemtap creates a
function and some global variables for mapping to event ID
numbers. We generate multiple -simpletrace.stp files though,
one per target and systemtap considers functions & variables
to be globally scoped, not per file. So if trying to use the
simpletrace compat probes, systemtap will complain:

 # stap -e 'probe qemu.system.arm.simpletrace.visit_type_str { print( "hello")}'
 semantic error: conflicting global variables: identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-aarch64-simpletrace.stp:3:8
        source: global event_name_to_id_map
                       ^
 identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-system-arm-simpletrace.stp:3:8
        source: global event_name_to_id_map
                       ^

 WARNING: cross-file global variable reference to identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-system-arm-simpletrace.stp:3:8 from: identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-aarch64-simpletrace.stp:8:21
 source:     if (!([name] in event_name_to_id_map)) {
                             ^
 WARNING: cross-file global variable reference to identifier 'event_next_id' at /usr/share/systemtap/tapset/qemu-system-arm-simpletrace.stp:4:8 from: identifier 'event_next_id' at :9:38
 source:         event_name_to_id_map[name] = event_next_id
                                              ^

We already have a string used to prefix probe names, so just
replace '.' with '_' to get a function / variable name prefix

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170728133657.5525-1-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-08-01 10:36:30 +01:00
Lluís Vilanova
1ff7b53196 trace: [tcg, trivial] Re-align generated code
Last patch removed a nesting level in generated code. Re-align all code
generated by backends to be 4-column aligned.

Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Emilio G. Cota <cota@braap.org>
Message-id: 149915824586.6295.17820926011082409033.stgit@frigg.lan
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-07-17 13:11:13 +01:00
Lluís Vilanova
864a2178d4 trace: [tcg] Do not generate TCG code to trace dynamically-disabled events
If an event is dynamically disabled, the TCG code that calls the
execution-time tracer is not generated.

Removes the overheads of execution-time tracers for dynamically disabled
events. As a bonus, also avoids checking the event state when the
execution-time tracer is called from TCG-generated code (since otherwise
TCG would simply not call it).

Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Emilio G. Cota <cota@braap.org>
Message-id: 149915799921.6295.13067154430923434035.stgit@frigg.lan
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-07-17 13:11:12 +01:00
Daniel P. Berrange
f3fddaf60b trace: disallow more than 10 arguments per trace event
The UST trace backend can only cope with upto 10 arguments. To ensure we
don't exceed the limit when UST is not compiled in, disallow more than
10 arguments upfront.

This prevents the case where:

  commit 0fc8aec7de
  Author: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
  Date:   Tue Apr 18 10:20:20 2017 +0800

    COLO-compare: Optimize tcp compare trace event

    Optimize two trace events as one, adjust print format make
    it easy to read. rename trace_colo_compare_pkt_info_src/dst
    to trace_colo_compare_tcp_info.

regressed the fix done in

  commit 2dfe5113b1
  Author: Alex Bennée <alex.bennee@linaro.org>
  Date:   Fri Oct 28 14:25:59 2016 +0100

    net: split colo_compare_pkt_info into two trace events

    It seems there is a limit to the number of arguments a UST trace event
    can take and at 11 the previous trace command broke the build. Split the
    trace into a src pkt and dst pkt trace to fix this.

    Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
    Message-id: 20161028132559.8324-1-alex.bennee@linaro.org
    Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Now we get an immediate fail even when UST is disabled:

  GEN     net/trace.h
Traceback (most recent call last):
  File "/home/berrange/src/virt/qemu/scripts/tracetool.py", line 154, in <module>
    main(sys.argv)
  File "/home/berrange/src/virt/qemu/scripts/tracetool.py", line 145, in main
    events.extend(tracetool.read_events(fh))
  File "/home/berrange/src/virt/qemu/scripts/tracetool/__init__.py", line 307, in read_events
    event = Event.build(line)
  File "/home/berrange/src/virt/qemu/scripts/tracetool/__init__.py", line 244, in build
    event = Event(name, props, fmt, args)
  File "/home/berrange/src/virt/qemu/scripts/tracetool/__init__.py", line 196, in __init__
    "argument count" % name)
ValueError: Event 'colo_compare_tcp_info' has more than maximum permitted argument count
Makefile:96: recipe for target 'net/trace.h-timestamp' failed

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20170426153900.21066-1-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-08 09:38:30 -04:00
Stefan Hajnoczi
7609ffb919 trace: fix tcg tracing build breakage
Commit 0ab8ed18a6 ("trace: switch to
modular code generation for sub-directories") forgot to convert "tcg"
trace events to the modular code generation approach where each
sub-directory has its own trace-events file.

This patch fixes compilation for "tcg" trace events.  Currently they are
only used in the root ./trace-events file.

"tcg" trace events can only be used in the root ./trace-events file for
the time being.

Reported-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20170327131718.18268-1-stefanha@redhat.com
Suggested-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-03-28 11:07:46 +01:00
Daniel P. Berrange
0ab8ed18a6 trace: switch to modular code generation for sub-directories
Introduce rules in the top level Makefile that are able to generate
trace.[ch] files in every subdirectory which has a trace-events file.

The top level directory is handled specially, so instead of creating
trace.h, it creates trace-root.h. This allows sub-directories to
include the top level trace-root.h file, without ambiguity wrt to
the trace.g file in the current sub-dir.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170125161417.31949-7-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-31 17:11:18 +00:00
Fam Zheng
db4df20de8 trace: Fix 'char **' compilation error in simple backend
Currently, the generated function body will do "strlen(arg)" but the
argument could be 'char **' or 'char * const *'. Avoid that by excluding
such cases in is_string check.

Reported by patchew's "make docker-test-mingw@fedora".

Suggested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1477453806-21097-1-git-send-email-famz@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-10-27 19:24:15 +01:00
Daniel P. Berrange
80dd5c4918 trace: introduce a formal group name for trace events
The declarations in the generated-tracers.h file are
assuming there's only ever going to be one instance
of this header, as they are not namespaced. When we
have one header per event group, if a single source
file needs to include multiple sets of trace events,
the symbols will all clash.

This change thus introduces a '--group NAME' arg to the
'tracetool' program. This will cause all the symbols in
the generated header files to be given a unique namespace.

If no group is given, the group name 'common' is used,
which is suitable for the current usage where there is
only one global trace-events file used for code generation.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Message-id: 1475588159-30598-21-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:54:53 +02:00
Daniel P. Berrange
9096b78a38 trace: push reading of events up a level to tracetool main
Move the reading of events out of the 'tracetool.generate'
method and into tracetool.main, so that the latter is not
tied to generating from a single source of events.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-19-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:54:52 +02:00
Daniel P. Berrange
d1b97bcea3 trace: rename _read_events to read_events
The _read_events method is used by callers outside of
its module, so should be a public method, not private.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-18-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:54:52 +02:00
Daniel P. Berrange
347701879c trace: get rid of generated-events.h/generated-events.c
Currently the generated-events.[ch] files contain the
event dstates, constants and TraceEvent structs, while the
generated-tracers.[ch] files contain the actual trace
probe logic. With the removal of usage of the event enums
from the API there is no longer any compelling reason for
the separation between these files. The generated-events.h
content is only ever needed from the generated-tracers.[ch]
files.

The enums/constants/structs from generated-events.[ch] are
thus moved into the generated-tracers.[ch], so that there
is one less file to be generated.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-17-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:54:52 +02:00
Daniel P. Berrange
ca3fa0e88f trace: dynamically allocate event IDs at runtime
Instead of having the code generator assign event IDs and
event VCPU IDs, assign them when the events are registered
at runtime. This will allow code to be generated from
individual trace-events without having to figure out
globally unique numbering at build time.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-16-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:54:52 +02:00
Daniel P. Berrange
fe4db84d49 trace: provide mechanism for registering trace events
Remove the notion of there being a single global array
of trace events, by introducing a method for registering
groups of events.

The module_call_init() needs to be invoked at the start
of any program that wants to make use of the trace
support. Currently this covers system emulators qemu-nbd,
qemu-img and qemu-io.

[Squashed the following fix from Daniel P. Berrange
<berrange@redhat.com>:

linux-user/bsd-user: initialize trace events subsystem

The bsd-user/linux-user programs make use of the CPU emulation
code and this now requires that the trace events subsystem
is enabled, otherwise it'll crash trying to allocate an empty
trace events bitmap for the CPU object.

--Stefan]

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-14-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:52:50 +02:00
Daniel P. Berrange
7f1b588f20 trace: emit name <-> ID mapping in simpletrace header
Currently simpletrace assumes that events are given IDs
starting from 0, based on the order in which they appear
in the trace-events file, with no gaps. When the
trace-events file is split up, this assumption becomes
problematic.

To deal with this, extend the simpletrace format so that
it outputs a table of event name <-> ID mappings. That
will allow QEMU to assign arbitrary IDs to events without
breaking simpletrace parsing.

The v3 simple trace format was

  FILE HEADER
  EVENT TRACE RECORD 0
  EVENT TRACE RECORD 1
  ...
  EVENT TRACE RECORD N

The v4 simple trace format is now

  FILE HEADER
  EVENT MAPPING RECORD 0
  EVENT MAPPING RECORD 1
  ...
  EVENT MAPPING RECORD M
  EVENT TRACE RECORD RECORD 0
  EVENT TRACE RECORD RECORD 1
  ...
  EVENT TRACE RECORD N

Although this shows all the mapping records being emitted
upfront, this is not required by the format. While the main
simpletrace backend will emit all mappings at startup,
the systemtap simpletrace.stp script will emit the mappings
at first use. eg

  FILE HEADER
  ...
  EVENT MAPPING RECORD 0
  EVENT TRACE RECORD RECORD 0
  EVENT TRACE RECORD RECORD 1
  EVENT MAPPING RECORD 1
  EVENT TRACE RECORD RECORD 2
  ...
  EVENT TRACE RECORD N

This is more space efficient given that most trace records
only include a subset of events.

In modifying the systemtap simpletrace code, a 'begin' probe
was added to emit the trace event header, so you no longer
need to add '--no-header' when running simpletrace.py for
systemtap generated trace files.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-12-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:35:54 +02:00
Daniel P. Berrange
ef4c9fc854 trace: remove the TraceEventID and TraceEventVCPUID enums
The TraceEventID and TraceEventVCPUID enums constants are
no longer actually used for anything critical.

The TRACE_EVENT_COUNT limit is used to determine the size
of the TraceEvents array, and can be removed if we just
NULL terminate the array instead.

The TRACE_VCPU_EVENT_COUNT limit is used as a magic value
for marking non-vCPU events, and also for declaring the
size of the trace dstate mask in the CPUState struct.
The former usage can be replaced by a dedicated constant
TRACE_EVENT_VCPU_NONE, defined as (uint32_t)-1. For the
latter usage, we can simply define a constant for the
number of VCPUs, avoiding the need for the full enum.

The only other usages of the enum values can be replaced
by accesing the id/vcpu_id fields via the named TraceEvent
structs.

Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-11-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:35:54 +02:00
Daniel P. Berrange
79218be42b trace: give each trace event a named TraceEvent struct
Currently we only expose a TraceEvent array, which must
be indexed via the TraceEventID enum constants. This
changes the generator to expose a named TraceEvent
instance for each event, with an _EVENT suffix.

Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-10-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:35:54 +02:00
Daniel P. Berrange
99672c7167 trace: remove duplicate control.h includes in generated-tracers.h
The format/h.py file adds an include for control.h to
generated-tracers.h. ftrace, log and syslog, then
add more duplicate includes for control.h.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-8-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-12 09:35:54 +02:00