qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Porting QEMU to new hosts with unusual ABI (sizeof(long


From: Rob Landley
Subject: Re: [Qemu-devel] Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
Date: Thu, 10 Feb 2011 23:05:08 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7

On 02/05/2011 08:39 AM, Stefan Weil wrote:
> Currently, most QEMU code assumes that pointers and long integers have
> the same size, typically 32 bit on 32 bit hosts, 64 bit on 64 bit hosts.

This is called the LP64 standard:

  http://www.unix.org/whitepapers/64bit.html

Which was created for a reason:

  http://www.unix.org/version2/whatsnew/lp64_wp.html

And which Linux, MacOSX, BSD, Solaris, android, iphone, you name it,
they all comply with.

> While this assumption works on QEMU's major hosts, it is not generally
> true.

It is generally true.  There is exactly one operating system that
decided to go its own way, and the insane legacy reasons they did so are
explained here:

  http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

> There exist 64 bit host OS which use an ABI with 32 bit long integers,
> maybe to be more compatible with an older 32 bit OS version, so here is
> sizeof(long) < sizeof(void *).

You're implying that someone actually uses 64 bit windows?

On 32 bit hosts, LP64 is fine.  Long and pointer match.  So the obvious
fix is to build QEMU for 32 bits on windows.

> Other ABIs might use "near" pointers which may reduce code size and improve
> code speed. This results in sizeof(long) > sizeof(void *).

Um, "near pointer" was dos.  That went away long enough ago that its
absence is just about old enough to vote.

> Both cases will break current QEMU, because lots of code lines use
> type casts from pointer to long or vice versa like these two examples:

Sucks to be Microsoft, doesn't it?  They have billions of dollars to
comfort them.

Rob



reply via email to

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