qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH] disas: Fix printing of addresses in


From: Peter Maydell
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] disas: Fix printing of addresses in disassembly
Date: Mon, 9 Jul 2012 14:26:09 +0100

On 9 July 2012 14:19, Andreas Färber <address@hidden> 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]  ; 0xffffffff80479a4f
>>
>> (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.)

>> +/* 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 = ~0ULL >> (64 - TARGET_VIRT_ADDR_SPACE_BITS);
>> +    generic_print_address(addr & mask, info);
>> +}

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

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.

> I'm thinking
> of the possibility of having an alias in the 64-bit address space point
> 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.

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.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]