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

[Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>]

On Fri, Nov 30, 2007 at 02:36:32PM +0900, Magnus Damm wrote:
> On Nov 19, 2007 6:18 AM, Carlo Marcelo Arenas Belon
> <carenas@sajinet.com.pe> 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

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.

> > Index: sh7750.c
> > ===================================================================
> > RCS file: /sources/qemu/qemu/hw/sh7750.c,v
> > retrieving revision 1.11
> > diff -u -r1.11 sh7750.c
> > --- sh7750.c    17 Nov 2007 17:14:48 -0000      1.11
> > +++ sh7750.c    18 Nov 2007 21:08:37 -0000
> 
> Could you please create the diff from the top level directory next
> time? That way it can be applied with patch -p0 or -p1 directly in the
> top level directory which makes patch handling much easier. Thanks!

sure, sorry about that, made the mistake when rebasing the patch for this
RESEND after a week has past without any feedback.

Carlo