On 25 January 2012 15:55, Xin Tong <[email protected]> wrote: > The segfault is caused by jumping to the middle of an instruction. so > i want to know which TB jumps here.
(a) Assuming it doesn't take too long to get there, you should be able to get this information by turning on the debug log via -d whatever. If it does take too long to get to the crash, you can use the savevm/loadvm support to save the VM state at some point slightly before the crash. Then you can run with the debug log enabled and '-loadvm tag' to start from the point when you saved the VM state. [disclaimer: depending on the guest machine you're emulating you might be unlucky and need to fix save/load first, but that's a worthwhile thing anyway :-)] (b) Might not be what you're seeing, but there's a class of bug that can look like a jump to the middle of an instruction that happens when: * step 1: we generate code for a TB * a load or store within that TB causes an exception * to get CPUState in sync with the point of the exception (and in particular to translate the host PC at the exception into the guest PC at that point) we call cpu_restore_state() * cpu_restore_state() calls gen_intermediate_code_pc() to request a retranslation of the TB with extra info to allow us to do a host-PC-to-guest-PC lookup * Note that gen_intermediate_code_pc() overwrites the generated code that already exists in memory, and stops as soon as it reaches the point of the exception. This is harmless because we are just rewriting the same bytes to memory that were there already, but disastrous if... * ...due to a bug, gen_intermediate_code_pc() generates different code to that generated back in step 1; this tends to result in writing half an instruction at the point where it stops * subsequent attempts to execute that TB tend to result in weird crashes, often looking like an attempt to jump into the middle of an instruction This is why it's critical that gen_intermediate_code()+TCG always deterministically generates exactly the same native code every time. -- PMM
