> > 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
