From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WImNJ-0008O9-Cc for qemu-devel@nongnu.org; Wed, 26 Feb 2014 16:50:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WImNA-000247-Tx for qemu-devel@nongnu.org; Wed, 26 Feb 2014 16:50:45 -0500 Received: from mail-pb0-x231.google.com ([2607:f8b0:400e:c01::231]:49959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WImNA-00023g-K2 for qemu-devel@nongnu.org; Wed, 26 Feb 2014 16:50:36 -0500 Received: by mail-pb0-f49.google.com with SMTP id jt11so1557879pbb.8 for ; Wed, 26 Feb 2014 13:50:35 -0800 (PST) Message-ID: <530E61A2.8070404@gmail.com> Date: Thu, 27 Feb 2014 05:50:26 +0800 From: Xuebing wang MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] How is address of helper function for slow path calculated ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Gaurav Sharma Cc: QEMU Developers Somebody may concisely refer tcg as a disassembler + a compiler (assembler). I guess your question is how to calculate the value of i386 register (%r10 in your case, the address for the helper function). I might be wrong, my understanding is that it is calculated by the assembler (to generate the "generated code"), specifically functions tcg_gen_helper32() or tcg_gen_helper64(). Hope this helps. On 02/26/2014 09:14 PM, Peter Maydell wrote: > On 26 February 2014 13:04, Gaurav Sharma wrote: >> Hi, >> I have been trying to trace the for how address translation is done for any >> load/store instructions. I was trying to emulate arm on an x86-64 machine. >> However, i need some clarifications : >> 1. During the slow path, qemu uses helper functions to translate address. >> 2. This is done by calling the function itself during the execution. >> 3. The host instrn for the slow path is added at the end of the TB block. I >> tried a sample code and got the following host instrn : >> 0x2aaade72d120: mov %r14,%rdi >> 0x2aaade72d123: xor %edx,%edx >> 0x2aaade72d125: lea -0x42(%rip),%rcx # 0x2aaade72d0ea >> 0x2aaade72d12c: mov $0x2afd98602c10,%r10 >> 0x2aaade72d136: callq *%r10 // Call helper function >> 0x2aaade72d139: mov %eax,%ebp >> 0x2aaade72d13b: jmpq 0x2aaade72d0ea >> >> 3. How does it gets the address of the helper function : >> call instruction is added by ' tcg_out_calli(s, >> (uintptr_t)qemu_ld_helpers[opc & ~MO_SIGN]' line of code which fetches the >> address of the helper function. >> However from the assembly generated, the address is calculated before : >> tcg_out_movi(s, TCG_TYPE_PTR, tcg_target_call_iarg_regs[3], >> (uintptr_t)l->raddr) > This is just loading the 4th argument for the helper function into ECX > (which is the return address in generated code which corresponds to > the load we're going to do). It's not related to the address of the > helper function at all. > >> How is the address for the helper function calculated ? > You've just quoted the code that does it: > tcg_out_calli(s, (uintptr_t)qemu_ld_helpers[opc & ~MO_SIGN]' ...) > > tcg_out_calli spots that the displacement is too big for a call insn > and emits the > 0x2aaade72d12c: mov $0x2afd98602c10,%r10 > 0x2aaade72d136: callq *%r10 // Call helper function > > thanks > -- PMM > > -- Thanks, Xuebing Wang