From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoF66-0005zX-TS for qemu-devel@nongnu.org; Mon, 09 Jul 2012 10:38:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoF5z-0008FU-Ji for qemu-devel@nongnu.org; Mon, 09 Jul 2012 10:37:58 -0400 Message-ID: <4FFAECBB.8070309@suse.de> Date: Mon, 09 Jul 2012 16:37:47 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1340636155-26426-1-git-send-email-peter.maydell@linaro.org> <4FFADA47.4050507@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] disas: Fix printing of addresses in disassembly List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Alexander Graf , qemu-ppc , qemu-devel@nongnu.org, patches@linaro.org Am 09.07.2012 15:26, schrieb Peter Maydell: > On 9 July 2012 14:19, Andreas F=C3=A4rber wrote: >> Am 25.06.2012 16:55, schrieb Peter Maydell: >>> In our disassembly code, the bfd_vma type is always 64 bits, >>> even if the target's virtual address width is only 32 bits. This >>> means that when we print out addresses we need to truncate them >>> to 32 bits, to avoid odd output which has incorrectly sign-extended >>> a value to 64 bits, for instance this ARM example: >>> 0x80479a60: e59f4088 ldr r4, [pc, #136] ; 0xffffffff80479a= 4f >>> >>> (It would also be possible to truncate before passing the address >>> to info->print_address_func(), but truncating in the final print >>> function is the same approach that binutils takes to this problem.) >=20 >>> +/* Print address in hex, truncated to the width of a target virtual = address. */ >>> +static void >>> +generic_print_target_address(bfd_vma addr, struct disassemble_info *= info) >>> +{ >>> + uint64_t mask =3D ~0ULL >> (64 - TARGET_VIRT_ADDR_SPACE_BITS); >>> + generic_print_address(addr & mask, info); >>> +} >=20 >> I wonder if TARGET_VIRT_ADDR_SPACE_BITS is the correct factor to use >> here though? Might sizeof(target_phys_addr_t) * 8 be safer? >=20 > That will give the wrong answer for ARM (when my LPAE patchset lands): > ARM virtual addresses are 32 bits but sizeof(target_phys_addr_t) * 8 > will be 64. Sorry, I'm mixing things up... VAS / PAS arm 32 / 40 i386 32 / 36 x86_64 47 / 52 ppc 32 / 36 ppc64 64 / 62 It's the physical address space where ppc64 is the oddball, so: Reviewed-by: Andreas F=C3=A4rber >> I'm thinking >> of the possibility of having an alias in the 64-bit address space poin= t >> into the actual 36/48/... virtual address space. I have a ppc64 ld >> instruction in mind, for which a full 64-bit register would be set up >> that could not fully be represented in the virtual address space. >=20 > It would be helpful to check how the ppc disassembler handles that > ld insn. It may well either (a) not print the resulting address at > all or (b) print it itself. However, if the resulting actual address > is a virtual address space then the right thing to print would be > the truncated version, I think, assuming that is what the hardware will > actually do the load from. I made a thinko: The disassembler would only show the register numbers for the ld instruction, and the register would be loaded by up to five instructions with 16-bit immediate (shifted) loads. So there would be no problem with the operands. The value printing at runtime is handled by the gdb stub instead. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg