diff options
author | Peter Maydell <peter.maydell@linaro.org> | 2020-10-13 13:26:58 +0100 |
---|---|---|
committer | Richard Henderson <richard.henderson@linaro.org> | 2020-10-27 09:48:07 -0700 |
commit | 1d705e8a5bbfe36294081baa45ab68a9ad987f33 (patch) | |
tree | 26be8d698649e0df4ebb2ff0c909907c32c81dfc /accel | |
parent | cd0372c515c4732d8bd3777cdd995c139c7ed7ea (diff) | |
download | qemu-1d705e8a5bbfe36294081baa45ab68a9ad987f33.zip qemu-1d705e8a5bbfe36294081baa45ab68a9ad987f33.tar.gz qemu-1d705e8a5bbfe36294081baa45ab68a9ad987f33.tar.bz2 |
accel/tcg: Add CPU_LOG_EXEC tracing for cpu_io_recompile()
When using -icount, it's useful for the CPU_LOG_EXEC logging
to include information about when cpu_io_recompile() was
called, because it alerts the reader of the log that the
tracing of a previous TB execution may not actually
correspond to an actually executed instruction. For instance
if you're using -icount and also -singlestep then a guest
instruction that makes an IO access appears in two
"Trace" lines, once in a TB that triggers the cpu_io_recompile()
and then again in the TB that actually executes.
(This is a similar reason to why the "Stopped execution of
TB chain before..." logging in cpu_tb_exec() is helpful
when trying to track execution flow in the logs.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20201013122658.4620-1-peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Diffstat (limited to 'accel')
-rw-r--r-- | accel/tcg/translate-all.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c index d760972..4572b49 100644 --- a/accel/tcg/translate-all.c +++ b/accel/tcg/translate-all.c @@ -2267,6 +2267,10 @@ void cpu_io_recompile(CPUState *cpu, uintptr_t retaddr) tb_destroy(tb); } + qemu_log_mask_and_addr(CPU_LOG_EXEC, tb->pc, + "cpu_io_recompile: rewound execution of TB to " + TARGET_FMT_lx "\n", tb->pc); + /* TODO: If env->pc != tb->pc (i.e. the faulting instruction was not * the first in the TB) then we end up generating a whole new TB and * repeating the fault, which is horribly inefficient. |