From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qa1qL-0001OK-S2 for qemu-devel@nongnu.org; Fri, 24 Jun 2011 04:34:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qa1qK-0003vl-06 for qemu-devel@nongnu.org; Fri, 24 Jun 2011 04:34:25 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:34053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qa1qJ-0003vd-KN for qemu-devel@nongnu.org; Fri, 24 Jun 2011 04:34:23 -0400 Received: by bwz16 with SMTP id 16so2360909bwz.4 for ; Fri, 24 Jun 2011 01:34:22 -0700 (PDT) From: Max Filippov Date: Fri, 24 Jun 2011 12:34:18 +0400 References: <201106240644.02325.jcmvbkbc@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106241234.19282.jcmvbkbc@gmail.com> Subject: Re: [Qemu-devel] Actual TB code doesn't look like what was intended (TCG issue)? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org > > 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