Re: [Qemu-devel] Actual TB code doesn't look like what was intended (TCG issue)?

[Max Filippov]

> > Please note how the current instruction in gdb differ from what
> > was said in OUT. This lea corrupts stack pointer and the next
> > callq generates segfault.
> > Could please anyone familiar with TCG take a look at this, or
> > suggest where I should look myself?
> 
> You don't say which target you're compiling code for, or what
> the input assembly was which triggered this.

I thought it doesn't matter. It's target-xtensa that I've been developing, 
input assembly is the following:

d00000c0 <_WindowUnderflow8>:
d00000c0:       09d910          l32e    a1, a9, -12
d00000c3:       09c900          l32e    a0, a9, -16
d00000c6:       09d170          l32e    a7, a1, -12
d00000c9:       09e920          l32e    a2, a9, -8
d00000cc:       09f930          l32e    a3, a9, -4
d00000cf:       098740          l32e    a4, a7, -32
d00000d2:       099750          l32e    a5, a7, -28
d00000d5:       09a760          l32e    a6, a7, -24
d00000d8:       09b770          l32e    a7, a7, -20
d00000db:       003500          rfwu

> My first guess is that the target's front end might have a bug
> where it wrongly bakes in assumptions about bits of the CPUState.
> QEMU will occasionally retranslate-in-place a TB (if a load in
> the TB causes an exception) so if the frontend generates different
> code the second time around things will go wrong...
> 
> You should be able to find out what's stomping on the code
> with the aid of a debugger and some watchpoints.

I just thought that "lea    -0x10(%rbx),%esp" may not appear in generated code 
at all, and in the OUT section (which is for different MMU mode, as I can see 
now) it is "lea    -0x10(%rbx),%r12d".
The instruction itself looks odd: it writes to esp and the sizes of the 
registers it operates on are different.

Thanks.
-- Max