qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] translate-all.c: fix debug memory maps printing


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] translate-all.c: fix debug memory maps printing
Date: Fri, 5 Sep 2014 10:09:15 +0100

On 5 September 2014 09:59, Mikhail Ilin <address@hidden> wrote:
> I also wonder we have separate linux-user emulators for i386 (32 bit
> ABI + 32 bit address space) and amd64 binaries (64 bit ABI + 64 bit
> address space). And we can not run 32 bits apps under qemu-x86_64 but
> MIPS N32 looks in some other way and it supports 32 bit ABI apps with
> 64 bit address space. I really not sure but is it a right design or
> not?

The design here is that we have one QEMU executable for each
Linux ABI we support. On MIPS there are a number of different
ABIs which may be in use even with the same CPU type, which
is why there are separate emulator binaries. On x86, if we ever
supported the x86_64 "x32" ABI, that would be an extra emulator
binary in addition to the current x86_64 and i386 ones.

This should all not matter much for core code, which simply
has to use the correct types for things. Quoting from HACKING:

vaddr is the best type to use to hold a CPU virtual address in
target-independent code. It is guaranteed to be large enough to hold a
virtual address for any target, and it does not change size from target
to target. It is always unsigned.
target_ulong is a type the size of a virtual address on the CPU; this means
it may be 32 or 64 bits depending on which target is being built. It should
therefore be used only in target-specific code, and in some
performance-critical built-per-target core code such as the TLB code.
There is also a signed version, target_long.
abi_ulong is for the *-user targets, and represents a type the size of
'void *' in that target's ABI. (This may not be the same as the size of a
full CPU virtual address in the case of target ABIs which use 32 bit pointers
on 64 bit CPUs, like sparc32plus.) Definitions of structures that must match
the target's ABI must use this type for anything that on the target is defined
to be an 'unsigned long' or a pointer type.
There is also a signed version, abi_long.

The problem you're running into here is with the ABIs where
abi_ulong and target_ulong are different sizes.

thanks
-- PMM



reply via email to

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