On 11/30/07, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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.
