On Wed, Jan 25, 2012 at 11:10 AM, Xin Tong <xerox.time.t...@gmail.com> wrote: > 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... > > > in the case you described above, which code guarantees that the > re-generated code is laid down in the place where the old code is. > This has to be do somewhere in tcg. > > > Xin > > > On Wed, Jan 25, 2012 at 1:58 PM, Xin Tong <xerox.time.t...@gmail.com> wrote: >> I am working on extending coremu (parallel version of qemu). >> Currently, the code cache in coremu is private, I am working towards >> to make it shared by all cores. I think the add_tb_jump may not be >> atomic. >> >> Thanks >> >> Xin >> >> On Wed, Jan 25, 2012 at 11:22 AM, Peter Maydell >> <peter.mayd...@linaro.org> wrote: >>> On 25 January 2012 15:55, Xin Tong <xerox.time.t...@gmail.com> 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 >
cpu_restore_state of translate-all.c. j = tcg_gen_code_search_pc(s, (uint8_t *)tc_ptr, searched_pc - tc_ptr); Maybe I don't understand your question. -Jim