Re: [Qemu-devel] TCG register allocator

[Xin Tong]

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 <address@hidden> 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
> <address@hidden> wrote:
>> On 25 January 2012 15:55, Xin Tong <address@hidden> 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