]>
Commit | Line | Data |
---|---|---|
e50caf4a SH |
1 | ======= |
2 | Tracing | |
3 | ======= | |
81a97d9d | 4 | |
e50caf4a SH |
5 | Introduction |
6 | ============ | |
81a97d9d SH |
7 | |
8 | This document describes the tracing infrastructure in QEMU and how to use it | |
9 | for debugging, profiling, and observing execution. | |
10 | ||
e50caf4a SH |
11 | Quickstart |
12 | ========== | |
81a97d9d | 13 | |
7e46d5f3 SH |
14 | Enable tracing of ``memory_region_ops_read`` and ``memory_region_ops_write`` |
15 | events:: | |
81a97d9d | 16 | |
7e46d5f3 SH |
17 | $ qemu --trace "memory_region_ops_*" ... |
18 | ... | |
19 | 719585@1608130130.441188:memory_region_ops_read cpu 0 mr 0x562fdfbb3820 addr 0x3cc value 0x67 size 1 | |
20 | 719585@1608130130.441190:memory_region_ops_write cpu 0 mr 0x562fdfbd2f00 addr 0x3d4 value 0x70e size 2 | |
81a97d9d | 21 | |
7e46d5f3 SH |
22 | This output comes from the "log" trace backend that is enabled by default when |
23 | ``./configure --enable-trace-backends=BACKENDS`` was not explicitly specified. | |
81a97d9d | 24 | |
3faf22ef SH |
25 | Multiple patterns can be specified by repeating the ``--trace`` option:: |
26 | ||
27 | $ qemu --trace "kvm_*" --trace "virtio_*" ... | |
28 | ||
29 | When patterns are used frequently it is more convenient to store them in a | |
30 | file to avoid long command-line options:: | |
81a97d9d | 31 | |
7e46d5f3 | 32 | $ echo "memory_region_ops_*" >/tmp/events |
3faf22ef | 33 | $ echo "kvm_*" >>/tmp/events |
7e46d5f3 | 34 | $ qemu --trace events=/tmp/events ... |
81a97d9d | 35 | |
e50caf4a SH |
36 | Trace events |
37 | ============ | |
81a97d9d | 38 | |
e50caf4a SH |
39 | Sub-directory setup |
40 | ------------------- | |
81a97d9d | 41 | |
0dfb3ca7 SH |
42 | Each directory in the source tree can declare a set of trace events in a local |
43 | "trace-events" file. All directories which contain "trace-events" files must be | |
44 | listed in the "trace_events_subdirs" variable in the top level meson.build | |
45 | file. During build, the "trace-events" file in each listed subdirectory will be | |
46 | processed by the "tracetool" script to generate code for the trace events. | |
d4fa8436 DB |
47 | |
48 | The individual "trace-events" files are merged into a "trace-events-all" file, | |
49 | which is also installed into "/usr/share/qemu" with the name "trace-events". | |
50 | This merged file is to be used by the "simpletrace.py" script to later analyse | |
51 | traces in the simpletrace data format. | |
52 | ||
0dfb3ca7 SH |
53 | The following files are automatically generated in <builddir>/trace/ during the |
54 | build: | |
d4fa8436 | 55 | |
0dfb3ca7 SH |
56 | - trace-<subdir>.c - the trace event state declarations |
57 | - trace-<subdir>.h - the trace event enums and probe functions | |
58 | - trace-dtrace-<subdir>.h - DTrace event probe specification | |
59 | - trace-dtrace-<subdir>.dtrace - DTrace event probe helper declaration | |
60 | - trace-dtrace-<subdir>.o - binary DTrace provider (generated by dtrace) | |
61 | - trace-ust-<subdir>.h - UST event probe helper declarations | |
d4fa8436 | 62 | |
0dfb3ca7 SH |
63 | Here <subdir> is the sub-directory path with '/' replaced by '_'. For example, |
64 | "accel/kvm" becomes "accel_kvm" and the final filename for "trace-<subdir>.c" | |
65 | becomes "trace-accel_kvm.c". | |
66 | ||
67 | Source files in the source tree do not directly include generated files in | |
68 | "<builddir>/trace/". Instead they #include the local "trace.h" file, without | |
69 | any sub-directory path prefix. eg io/channel-buffer.c would do:: | |
d4fa8436 DB |
70 | |
71 | #include "trace.h" | |
72 | ||
0dfb3ca7 SH |
73 | The "io/trace.h" file must be created manually with an #include of the |
74 | corresponding "trace/trace-<subdir>.h" file that will be generated in the | |
75 | builddir:: | |
76 | ||
77 | $ echo '#include "trace/trace-io.h"' >io/trace.h | |
78 | ||
79 | While it is possible to include a trace.h file from outside a source file's own | |
80 | sub-directory, this is discouraged in general. It is strongly preferred that | |
81 | all events be declared directly in the sub-directory that uses them. The only | |
82 | exception is where there are some shared trace events defined in the top level | |
83 | directory trace-events file. The top level directory generates trace files | |
84 | with a filename prefix of "trace/trace-root" instead of just "trace". This is | |
85 | to avoid ambiguity between a trace.h in the current directory, vs the top level | |
86 | directory. | |
d4fa8436 | 87 | |
e50caf4a SH |
88 | Using trace events |
89 | ------------------ | |
1412cf58 | 90 | |
e50caf4a | 91 | Trace events are invoked directly from source code like this:: |
81a97d9d SH |
92 | |
93 | #include "trace.h" /* needed for trace event prototype */ | |
49926043 | 94 | |
4b710a3c | 95 | void *qemu_vmalloc(size_t size) |
81a97d9d SH |
96 | { |
97 | void *ptr; | |
4b710a3c LV |
98 | size_t align = QEMU_VMALLOC_ALIGN; |
99 | ||
100 | if (size < align) { | |
101 | align = getpagesize(); | |
81a97d9d | 102 | } |
4b710a3c LV |
103 | ptr = qemu_memalign(align, size); |
104 | trace_qemu_vmalloc(size, ptr); | |
81a97d9d SH |
105 | return ptr; |
106 | } | |
107 | ||
e50caf4a SH |
108 | Declaring trace events |
109 | ---------------------- | |
81a97d9d | 110 | |
7b92e5bc | 111 | The "tracetool" script produces the trace.h header file which is included by |
81a97d9d | 112 | every source file that uses trace events. Since many source files include |
7b92e5bc LV |
113 | trace.h, it uses a minimum of types and other header files included to keep the |
114 | namespace clean and compile times and dependencies down. | |
81a97d9d SH |
115 | |
116 | Trace events should use types as follows: | |
117 | ||
118 | * Use stdint.h types for fixed-size types. Most offsets and guest memory | |
119 | addresses are best represented with uint32_t or uint64_t. Use fixed-size | |
120 | types over primitive types whose size may change depending on the host | |
121 | (32-bit versus 64-bit) so trace events don't truncate values or break | |
122 | the build. | |
123 | ||
124 | * Use void * for pointers to structs or for arrays. The trace.h header | |
125 | cannot include all user-defined struct declarations and it is therefore | |
126 | necessary to use void * for pointers to structs. | |
127 | ||
128 | * For everything else, use primitive scalar types (char, int, long) with the | |
129 | appropriate signedness. | |
130 | ||
ec09f877 SH |
131 | * Avoid floating point types (float and double) because SystemTap does not |
132 | support them. In most cases it is possible to round to an integer type | |
133 | instead. This may require scaling the value first by multiplying it by 1000 | |
134 | or the like when digits after the decimal point need to be preserved. | |
135 | ||
9a85d394 SH |
136 | Format strings should reflect the types defined in the trace event. Take |
137 | special care to use PRId64 and PRIu64 for int64_t and uint64_t types, | |
913540a3 | 138 | respectively. This ensures portability between 32- and 64-bit platforms. |
9f7ad79c PMD |
139 | Format strings must not end with a newline character. It is the responsibility |
140 | of backends to adapt line ending for proper logging. | |
9a85d394 | 141 | |
d4fa8436 | 142 | Each event declaration will start with the event name, then its arguments, |
e50caf4a | 143 | finally a format string for pretty-printing. For example:: |
d4fa8436 DB |
144 | |
145 | qemu_vmalloc(size_t size, void *ptr) "size %zu ptr %p" | |
146 | qemu_vfree(void *ptr) "ptr %p" | |
147 | ||
148 | ||
e50caf4a SH |
149 | Hints for adding new trace events |
150 | --------------------------------- | |
81a97d9d SH |
151 | |
152 | 1. Trace state changes in the code. Interesting points in the code usually | |
153 | involve a state change like starting, stopping, allocating, freeing. State | |
154 | changes are good trace events because they can be used to understand the | |
155 | execution of the system. | |
156 | ||
157 | 2. Trace guest operations. Guest I/O accesses like reading device registers | |
158 | are good trace events because they can be used to understand guest | |
159 | interactions. | |
160 | ||
161 | 3. Use correlator fields so the context of an individual line of trace output | |
162 | can be understood. For example, trace the pointer returned by malloc and | |
163 | used as an argument to free. This way mallocs and frees can be matched up. | |
164 | Trace events with no context are not very useful. | |
165 | ||
166 | 4. Name trace events after their function. If there are multiple trace events | |
167 | in one function, append a unique distinguisher at the end of the name. | |
168 | ||
e50caf4a SH |
169 | Generic interface and monitor commands |
170 | ====================================== | |
31965ae2 | 171 | |
b1bae816 LV |
172 | You can programmatically query and control the state of trace events through a |
173 | backend-agnostic interface provided by the header "trace/control.h". | |
31965ae2 | 174 | |
b1bae816 LV |
175 | Note that some of the backends do not provide an implementation for some parts |
176 | of this interface, in which case QEMU will just print a warning (please refer to | |
177 | header "trace/control.h" to see which routines are backend-dependent). | |
31965ae2 | 178 | |
b1bae816 | 179 | The state of events can also be queried and modified through monitor commands: |
31965ae2 | 180 | |
e50caf4a | 181 | * ``info trace-events`` |
31965ae2 LV |
182 | View available trace events and their state. State 1 means enabled, state 0 |
183 | means disabled. | |
184 | ||
e50caf4a | 185 | * ``trace-event NAME on|off`` |
b1bae816 | 186 | Enable/disable a given trace event or a group of events (using wildcards). |
31965ae2 | 187 | |
db817b8c | 188 | The "--trace events=<file>" command line argument can be used to enable the |
23d15e86 LV |
189 | events listed in <file> from the very beginning of the program. This file must |
190 | contain one event name per line. | |
191 | ||
db817b8c | 192 | If a line in the "--trace events=<file>" file begins with a '-', the trace event |
8f5a0fb1 SH |
193 | will be disabled instead of enabled. This is useful when a wildcard was used |
194 | to enable an entire family of events but one noisy event needs to be disabled. | |
195 | ||
b1bae816 LV |
196 | Wildcard matching is supported in both the monitor command "trace-event" and the |
197 | events list file. That means you can enable/disable the events having a common | |
198 | prefix in a batch. For example, virtio-blk trace events could be enabled using | |
e50caf4a | 199 | the following monitor command:: |
b1bae816 LV |
200 | |
201 | trace-event virtio_blk_* on | |
202 | ||
e50caf4a SH |
203 | Trace backends |
204 | ============== | |
81a97d9d | 205 | |
7b92e5bc | 206 | The "tracetool" script automates tedious trace event code generation and also |
81a97d9d SH |
207 | keeps the trace event declarations independent of the trace backend. The trace |
208 | events are not tightly coupled to a specific trace backend, such as LTTng or | |
7b92e5bc | 209 | SystemTap. Support for trace backends can be added by extending the "tracetool" |
81a97d9d SH |
210 | script. |
211 | ||
e50caf4a | 212 | The trace backends are chosen at configure time:: |
81a97d9d | 213 | |
7e46d5f3 | 214 | ./configure --enable-trace-backends=simple,dtrace |
81a97d9d SH |
215 | |
216 | For a list of supported trace backends, try ./configure --help or see below. | |
b73e8bd4 | 217 | If multiple backends are enabled, the trace is sent to them all. |
81a97d9d | 218 | |
3b0fc80d PM |
219 | If no backends are explicitly selected, configure will default to the |
220 | "log" backend. | |
221 | ||
81a97d9d SH |
222 | The following subsections describe the supported trace backends. |
223 | ||
e50caf4a SH |
224 | Nop |
225 | --- | |
81a97d9d SH |
226 | |
227 | The "nop" backend generates empty trace event functions so that the compiler | |
3b0fc80d PM |
228 | can optimize out trace events completely. This imposes no performance |
229 | penalty. | |
81a97d9d | 230 | |
dd215f64 LV |
231 | Note that regardless of the selected trace backend, events with the "disable" |
232 | property will be generated with the "nop" backend. | |
233 | ||
e50caf4a SH |
234 | Log |
235 | --- | |
b48c20f7 | 236 | |
ab8eb29c | 237 | The "log" backend sends trace events directly to standard error. This |
b48c20f7 SH |
238 | effectively turns trace events into debug printfs. |
239 | ||
240 | This is the simplest backend and can be used together with existing code that | |
241 | uses DPRINTF(). | |
242 | ||
418ed142 SH |
243 | The -msg timestamp=on|off command-line option controls whether or not to print |
244 | the tid/timestamp prefix for each trace event. | |
245 | ||
e50caf4a SH |
246 | Simpletrace |
247 | ----------- | |
81a97d9d | 248 | |
7e46d5f3 SH |
249 | The "simple" backend writes binary trace logs to a file from a thread, making |
250 | it lower overhead than the "log" backend. A Python API is available for writing | |
251 | offline trace file analysis scripts. It may not be as powerful as | |
252 | platform-specific or third-party trace backends but it is portable and has no | |
253 | special library dependencies. | |
81a97d9d | 254 | |
e50caf4a SH |
255 | Monitor commands |
256 | ~~~~~~~~~~~~~~~~ | |
c72e3e48 | 257 | |
e50caf4a | 258 | * ``trace-file on|off|flush|set <path>`` |
c72e3e48 SH |
259 | Enable/disable/flush the trace file or set the trace file name. |
260 | ||
e50caf4a SH |
261 | Analyzing trace files |
262 | ~~~~~~~~~~~~~~~~~~~~~ | |
c72e3e48 SH |
263 | |
264 | The "simple" backend produces binary trace files that can be formatted with the | |
265 | simpletrace.py script. The script takes the "trace-events-all" file and the | |
e50caf4a | 266 | binary trace:: |
c72e3e48 SH |
267 | |
268 | ./scripts/simpletrace.py trace-events-all trace-12345 | |
269 | ||
270 | You must ensure that the same "trace-events-all" file was used to build QEMU, | |
271 | otherwise trace event declarations may have changed and output will not be | |
272 | consistent. | |
273 | ||
e50caf4a SH |
274 | Ftrace |
275 | ------ | |
e64dd5ef ET |
276 | |
277 | The "ftrace" backend writes trace data to ftrace marker. This effectively | |
278 | sends trace events to ftrace ring buffer, and you can compare qemu trace | |
279 | data and kernel(especially kvm.ko when using KVM) trace data. | |
280 | ||
e50caf4a | 281 | if you use KVM, enable kvm events in ftrace:: |
e64dd5ef ET |
282 | |
283 | # echo 1 > /sys/kernel/debug/tracing/events/kvm/enable | |
284 | ||
e50caf4a | 285 | After running qemu by root user, you can get the trace:: |
e64dd5ef ET |
286 | |
287 | # cat /sys/kernel/debug/tracing/trace | |
288 | ||
289 | Restriction: "ftrace" backend is restricted to Linux only. | |
290 | ||
e50caf4a SH |
291 | Syslog |
292 | ------ | |
0a852417 PD |
293 | |
294 | The "syslog" backend sends trace events using the POSIX syslog API. The log | |
295 | is opened specifying the LOG_DAEMON facility and LOG_PID option (so events | |
296 | are tagged with the pid of the particular QEMU process that generated | |
297 | them). All events are logged at LOG_INFO level. | |
298 | ||
299 | NOTE: syslog may squash duplicate consecutive trace events and apply rate | |
300 | limiting. | |
301 | ||
302 | Restriction: "syslog" backend is restricted to POSIX compliant OS. | |
303 | ||
e50caf4a SH |
304 | LTTng Userspace Tracer |
305 | ---------------------- | |
81a97d9d SH |
306 | |
307 | The "ust" backend uses the LTTng Userspace Tracer library. There are no | |
308 | monitor commands built into QEMU, instead UST utilities should be used to list, | |
309 | enable/disable, and dump traces. | |
b48c20f7 | 310 | |
ef3ef4a0 MG |
311 | Package lttng-tools is required for userspace tracing. You must ensure that the |
312 | current user belongs to the "tracing" group, or manually launch the | |
313 | lttng-sessiond daemon for the current user prior to running any instance of | |
314 | QEMU. | |
315 | ||
316 | While running an instrumented QEMU, LTTng should be able to list all available | |
e50caf4a | 317 | events:: |
ef3ef4a0 MG |
318 | |
319 | lttng list -u | |
320 | ||
e50caf4a | 321 | Create tracing session:: |
ef3ef4a0 MG |
322 | |
323 | lttng create mysession | |
324 | ||
e50caf4a | 325 | Enable events:: |
ef3ef4a0 MG |
326 | |
327 | lttng enable-event qemu:g_malloc -u | |
328 | ||
329 | Where the events can either be a comma-separated list of events, or "-a" to | |
e50caf4a | 330 | enable all tracepoint events. Start and stop tracing as needed:: |
ef3ef4a0 MG |
331 | |
332 | lttng start | |
333 | lttng stop | |
334 | ||
e50caf4a | 335 | View the trace:: |
ef3ef4a0 MG |
336 | |
337 | lttng view | |
338 | ||
e50caf4a | 339 | Destroy tracing session:: |
ef3ef4a0 MG |
340 | |
341 | lttng destroy | |
342 | ||
e50caf4a | 343 | Babeltrace can be used at any later time to view the trace:: |
ef3ef4a0 MG |
344 | |
345 | babeltrace $HOME/lttng-traces/mysession-<date>-<time> | |
346 | ||
e50caf4a SH |
347 | SystemTap |
348 | --------- | |
b48c20f7 SH |
349 | |
350 | The "dtrace" backend uses DTrace sdt probes but has only been tested with | |
351 | SystemTap. When SystemTap support is detected a .stp file with wrapper probes | |
352 | is generated to make use in scripts more convenient. This step can also be | |
353 | performed manually after a build in order to change the binary name in the .stp | |
e50caf4a | 354 | probes:: |
b48c20f7 | 355 | |
2e4ccbbc LM |
356 | scripts/tracetool.py --backends=dtrace --format=stap \ |
357 | --binary path/to/qemu-binary \ | |
358 | --target-type system \ | |
359 | --target-name x86_64 \ | |
bd200384 | 360 | --group=all \ |
c05012a3 SH |
361 | trace-events-all \ |
362 | qemu.stp | |
b7d66a76 | 363 | |
62dd1048 DB |
364 | To facilitate simple usage of systemtap where there merely needs to be printf |
365 | logging of certain probes, a helper script "qemu-trace-stap" is provided. | |
366 | Consult its manual page for guidance on its usage. | |
367 | ||
e50caf4a SH |
368 | Trace event properties |
369 | ====================== | |
b7d66a76 | 370 | |
1412cf58 | 371 | Each event in the "trace-events-all" file can be prefixed with a space-separated |
b7d66a76 LV |
372 | list of zero or more of the following event properties. |
373 | ||
e50caf4a SH |
374 | "disable" |
375 | --------- | |
b7d66a76 LV |
376 | |
377 | If a specific trace event is going to be invoked a huge number of times, this | |
378 | might have a noticeable performance impact even when the event is | |
379 | programmatically disabled. | |
380 | ||
381 | In this case you should declare such event with the "disable" property. This | |
382 | will effectively disable the event at compile time (by using the "nop" backend), | |
383 | thus having no performance impact at all on regular builds (i.e., unless you | |
1412cf58 | 384 | edit the "trace-events-all" file). |
b7d66a76 LV |
385 | |
386 | In addition, there might be cases where relatively complex computations must be | |
387 | performed to generate values that are only used as arguments for a trace | |
1aa6430d PM |
388 | function. In these cases you can use 'trace_event_get_state_backends()' to |
389 | guard such computations, so they are skipped if the event has been either | |
390 | compile-time disabled or run-time disabled. If the event is compile-time | |
391 | disabled, this check will have no performance impact. | |
b7d66a76 | 392 | |
e50caf4a SH |
393 | :: |
394 | ||
b7d66a76 LV |
395 | #include "trace.h" /* needed for trace event prototype */ |
396 | ||
397 | void *qemu_vmalloc(size_t size) | |
398 | { | |
399 | void *ptr; | |
400 | size_t align = QEMU_VMALLOC_ALIGN; | |
401 | ||
402 | if (size < align) { | |
403 | align = getpagesize(); | |
404 | } | |
405 | ptr = qemu_memalign(align, size); | |
1aa6430d | 406 | if (trace_event_get_state_backends(TRACE_QEMU_VMALLOC)) { |
b7d66a76 LV |
407 | void *complex; |
408 | /* some complex computations to produce the 'complex' value */ | |
409 | trace_qemu_vmalloc(size, ptr, complex); | |
410 | } | |
411 | return ptr; | |
412 | } | |
b1bae816 | 413 | |
e50caf4a SH |
414 | "tcg" |
415 | ----- | |
0bb403b0 LV |
416 | |
417 | Guest code generated by TCG can be traced by defining an event with the "tcg" | |
418 | event property. Internally, this property generates two events: | |
419 | "<eventname>_trans" to trace the event at translation time, and | |
420 | "<eventname>_exec" to trace the event at execution time. | |
421 | ||
422 | Instead of using these two events, you should instead use the function | |
423 | "trace_<eventname>_tcg" during translation (TCG code generation). This function | |
424 | will automatically call "trace_<eventname>_trans", and will generate the | |
425 | necessary TCG code to call "trace_<eventname>_exec" during guest code execution. | |
426 | ||
427 | Events with the "tcg" property can be declared in the "trace-events" file with a | |
428 | mix of native and TCG types, and "trace_<eventname>_tcg" will gracefully forward | |
429 | them to the "<eventname>_trans" and "<eventname>_exec" events. Since TCG values | |
430 | are not known at translation time, these are ignored by the "<eventname>_trans" | |
431 | event. Because of this, the entry in the "trace-events" file needs two printing | |
e50caf4a | 432 | formats (separated by a comma):: |
0bb403b0 LV |
433 | |
434 | tcg foo(uint8_t a1, TCGv_i32 a2) "a1=%d", "a1=%d a2=%d" | |
435 | ||
e50caf4a | 436 | For example:: |
0bb403b0 LV |
437 | |
438 | #include "trace-tcg.h" | |
439 | ||
440 | void some_disassembly_func (...) | |
441 | { | |
442 | uint8_t a1 = ...; | |
443 | TCGv_i32 a2 = ...; | |
444 | trace_foo_tcg(a1, a2); | |
445 | } | |
446 | ||
e50caf4a | 447 | This will immediately call:: |
0bb403b0 LV |
448 | |
449 | void trace_foo_trans(uint8_t a1); | |
450 | ||
e50caf4a | 451 | and will generate the TCG code to call:: |
0bb403b0 LV |
452 | |
453 | void trace_foo(uint8_t a1, uint32_t a2); | |
3d211d9f | 454 | |
e50caf4a SH |
455 | "vcpu" |
456 | ------ | |
3d211d9f LV |
457 | |
458 | Identifies events that trace vCPU-specific information. It implicitly adds a | |
459 | "CPUState*" argument, and extends the tracing print format to show the vCPU | |
460 | information. If used together with the "tcg" property, it adds a second | |
461 | "TCGv_env" argument that must point to the per-target global TCG register that | |
462 | points to the vCPU when guest code is executed (usually the "cpu_env" variable). | |
463 | ||
7609ffb9 SH |
464 | The "tcg" and "vcpu" properties are currently only honored in the root |
465 | ./trace-events file. | |
466 | ||
e50caf4a | 467 | The following example events:: |
3d211d9f LV |
468 | |
469 | foo(uint32_t a) "a=%x" | |
470 | vcpu bar(uint32_t a) "a=%x" | |
471 | tcg vcpu baz(uint32_t a) "a=%x", "a=%x" | |
472 | ||
e50caf4a | 473 | Can be used as:: |
3d211d9f LV |
474 | |
475 | #include "trace-tcg.h" | |
476 | ||
477 | CPUArchState *env; | |
478 | TCGv_ptr cpu_env; | |
479 | ||
480 | void some_disassembly_func(...) | |
481 | { | |
482 | /* trace emitted at this point */ | |
483 | trace_foo(0xd1); | |
484 | /* trace emitted at this point */ | |
29a0af61 | 485 | trace_bar(env_cpu(env), 0xd2); |
3d211d9f | 486 | /* trace emitted at this point (env) and when guest code is executed (cpu_env) */ |
29a0af61 | 487 | trace_baz_tcg(env_cpu(env), cpu_env, 0xd3); |
3d211d9f LV |
488 | } |
489 | ||
490 | If the translating vCPU has address 0xc1 and code is later executed by vCPU | |
e50caf4a | 491 | 0xc2, this would be an example output:: |
3d211d9f LV |
492 | |
493 | // at guest code translation | |
494 | foo a=0xd1 | |
495 | bar cpu=0xc1 a=0xd2 | |
496 | baz_trans cpu=0xc1 a=0xd3 | |
497 | // at guest code execution | |
498 | baz_exec cpu=0xc2 a=0xd3 |