qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] [RESEND] hw/sh7750.c: use TARGET_FMT_plx to pri


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] [RESEND] hw/sh7750.c: use TARGET_FMT_plx to printf target_phys_addr_t
Date: Fri, 30 Nov 2007 17:37:35 +0200

On 11/30/07, Carlo Marcelo Arenas Belon <address@hidden> wrote:
> On Fri, Nov 30, 2007 at 02:36:32PM +0900, Magnus Damm wrote:
> > On Nov 19, 2007 6:18 AM, Carlo Marcelo Arenas Belon
> > <address@hidden> wrote:
> > > The following patch changes the formatting string from %08x to 
> > > TARGET_FMT_plx
> > > to accommodate for compilation in 64bit hosts and that manifests with the
> > > following warning :
> > >
> > >   qemu/hw/sh7750.c: In function `error_access':
> > >   qemu/hw/sh7750.c:186: warning: unsigned int format, different type arg 
> > > (arg 5)
> > >   qemu/hw/sh7750.c: In function `ignore_access':
> > >   qemu/hw/sh7750.c:192: warning: unsigned int format, different type arg 
> > > (arg 5)
> >
> > This patch works fine on 32 bit x86 hosts. Please apply.
>
> Thanks, forgot to mention that I tested it of course as well in 32 bit x86
> where the code is equivalent as cpu-defs.h defines for 32 bit targets :
>
> #define TARGET_FMT_plx "%08x"
>
> For 64 bit targets, it will use a 64 bit type for physical addresses and
> therefore a 64 bit wide format as defined by :
>
> #define TARGET_FMT_plx "%016" PRIx64
>
> which might not be what was intended originally and might be uncovering a bug
> somewhere else and based on the fact that apparently (and this gets confusing
> as it seems to be inconsistently used everywhere in qemu) :
>
>   target_phys_addr_t = physical address of the host
>   ram_addr_t = physical address of the guest

No, target_phys_addr_t is the physical address of the emulated target
system. For host addresses ram_addr_t, unsigned long or even int is
used. Host addresses are of course virtual, Qemu is a user space
application until someone makes it run in bare metal without OS.

> and so all this function should had been using ram_addr_t instead, and that
> would need to be redefined to be 64 bit safe and have as well a new formatting
> string to match that.

No.




reply via email to

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