[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Incomplete '-d exec' traces?

From: Peter Maydell
Subject: Re: [Qemu-discuss] Incomplete '-d exec' traces?
Date: Sat, 10 Jan 2015 00:03:49 +0000

On 9 January 2015 at 21:23, Evan Driscoll <address@hidden> wrote:
> I am running an ARM program in single-process mode with '-d exec', and
> either the resulting traces are incomplete, I don't understand them, or
> something else is going on. Tried with QEMU 2.2.0; more detailed info about
> how things are built & run.
> The suspicious part of the trace is:
> ----------------
> IN: _IO_cleanup
> 0x0000cc94:  e585606c      str  r6, [r5, #108]
> 0x0000cc98:  e5955034      ldr  r5, [r5, #52]
> 0x0000cc9c:  e3550000      cmp  r5, #0  ; 0x0
> 0x0000cca0:  1affffca      bne  0xcbd0
> Trace 0x7f448997aba0 [0000cc94] _IO_cleanup
> ...
> Trace 0x7f8fb3b543c0 [0000cbec] _IO_cleanup
> Trace 0x7f8fb3b54200 [0000cc94] _IO_cleanup   <---
> Trace 0x7f8fb3b54200 [0000cc94] _IO_cleanup<---** here **
> In other words, it seems like the block starting at the guest's address
> 0xCC94 has two possible successors, 0xCCA4 (bne not taken) and 0xCBD0 (bne
> taken). But at least if I am inferring the log format correctly, the lines
> marked with "<--" should be indicating that the 0xCC94 block is executed
> twice in a row, but 0xCC94 isn't a successor of 0xCCA0.
> Any idea what is happening?

You're likely seeing the results of QEMU's TB chaining optimization.
Basically, if a jump target (or conditional jump target) is to a
known TB that we have already translated, we will patch it so that
we jump directly from one TB to the next without coming back out
to the inner loop. When we do this we won't log the execution of
the second and subsequent TBs in a chain, because the logging happens
in the cpu-exec loop.

You can check whether this is the issue by commenting out the call
to tb_add_jump() in cpu-exec.c, which will disable the optimization.

(I did at one point have some patches that logged the creation of the
chains (which would let you reconstruct execution from the log) but
they were a bit hacky because they didn't log when we unlinked a
chain again.)

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]