Re: [Qemu-devel] TCG register allocator

[James Greensky <gsky51@gmail.com>]

On Wed, Jan 25, 2012 at 11:10 AM, Xin Tong <xerox.time.tech@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.tech@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.maydell@linaro.org> wrote:
>>> On 25 January 2012 15:55, Xin Tong <xerox.time.tech@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