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

[Andreas Färber]

Am 09.07.2012 15:26, schrieb Peter Maydell:
> 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.

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ärber <address@hidden>

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

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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg