From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:40916)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1Qa1ra-0001bc-FH
	for qemu-devel@nongnu.org; Fri, 24 Jun 2011 04:35:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1Qa1rX-00046k-Ot
	for qemu-devel@nongnu.org; Fri, 24 Jun 2011 04:35:42 -0400
Received: from mail-bw0-f45.google.com ([209.85.214.45]:55877)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1Qa1rX-00046S-6P
	for qemu-devel@nongnu.org; Fri, 24 Jun 2011 04:35:39 -0400
Received: by bwz16 with SMTP id 16so2361420bwz.4
	for <qemu-devel@nongnu.org>; Fri, 24 Jun 2011 01:35:38 -0700 (PDT)
From: Max Filippov <jcmvbkbc@gmail.com>
Date: Fri, 24 Jun 2011 12:35:35 +0400
References: <201106240644.02325.jcmvbkbc@gmail.com>
	<BANLkTikCR5342Yd2fCJGDWS8Jny+L+qjfg@mail.gmail.com>
In-Reply-To: <BANLkTikCR5342Yd2fCJGDWS8Jny+L+qjfg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201106241235.35336.jcmvbkbc@gmail.com>
Subject: Re: [Qemu-devel] Actual TB code doesn't look like what was intended
	(TCG issue)?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Laurent Desnogues <laurent.desnogues@gmail.com>
Cc: qemu-devel@nongnu.org

> > Hello guys.
> >
> > I'm running qemu on x86_64 host.
> > It's clean build from git sources dated 2011.05.19, commit 1fddfba129f5435c80eda14e8bc23fdb888c7187
> > I have the following output from "log trace,op,out_asm":
> >
> > Trace 0x4000a310 [d0026c92]
> > OP:
> >  ---- 0xd00000c0
> >  movi_i32 tmp1,$0xfffffff4
> >  add_i32 tmp0,ar9,tmp1
> >  qemu_ld32 ar1,tmp0,$0x0
> >
> >  ---- 0xd00000c3
> >  movi_i32 tmp1,$0xfffffff0
> >  add_i32 tmp0,ar9,tmp1
> >  qemu_ld32 ar0,tmp0,$0x0
> >
> > [...snip...]
> [...]
> > 0x4000a360:  xor    %esi,%esi
> > 0x4000a362:  callq  0x52edc2
> [...]
> > (gdb) x/25i 0x4000a330
> [...]
> >   0x4000a360:  mov    $0x1,%esi
> >   0x4000a365:  callq  0x52edc2 <__ldl_mmu>
> >   0x4000a36a:  mov    %eax,%ebp
> >   0x4000a36c:  sub    $0x44,%al
> > => 0x4000a36e:  lea    -0x10(%rbx),%esp
> >   0x4000a371:  mov    %ebp,0xc(%r14)
> >   0x4000a375:  mov    %r12d,%esi
> >   0x4000a378:  mov    %r12d,%edi
> >
> > 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?
> 
> As Peter hinted, you're not looking at the code you think :-)
> Note how your original TCG code does loads:
> 
>    qemu_ld32 ar1,tmp0,$0x0
> 
> That $0x0 will end up in %RSI.  It's the mem index used to
> distinguish from user and privileged level accesses.  In your
> examples of host code, in one case it is 0 and in the other
> it is 1, so you're definitely not really looking at the same
> block in the same running conditions.

Yes, I've noticed it (however, after I sent this mail).
But (1) quoted OUT is the last OUT for this host address range in the log and (2) in gdb I set "b tlb_fill if retaddr == 0x4000a369" and made some steps.
You mean that I should look at previous OUTs for this address range?

Thanks.
-- Max