as I mentioned. In my current implementation of coremu, the code could be executed when it is modified. so the modifications need to be atomic. I think I need a scratch area in which the restore_cpu_state needs to be generated while leaving the already generated code in tact. would this solve the problem ?
Thanks Xin On Wed, Jan 25, 2012 at 2:23 PM, Peter Maydell <[email protected]> wrote: > On 25 January 2012 19:10, Xin Tong <[email protected]> wrote: > Peter Maydell 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. > > Actually, it's not in TCG but in the bit of QEMU which calls TCG. > > When we first translate a block of code we decide where its > generated code will sit (in exec.c:tb_gen_code()) and set tb->tc_ptr > to point at this location. Then when translate-all.c:cpu_gen_code() > does this first translation it passes tcg_gen_code() a gen_code_buf > argument which is this tb->tc_ptr. > Later if we need to do a restore, translate-all.c:cpu_restore_state() > calls tcg_gen_code_search_pc(), and again it passes a gen_code_buf > argument for where generated code should be written. It uses tb->tc_ptr > for the TranslationBlock, so it will always be at the same place. > > -- PMM
