From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Cc: blauwirbel@gmail.com
Subject: Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Date: Fri, 12 Oct 2007 00:00:40 +0200 [thread overview]
Message-ID: <1192140040.9976.235.camel@rapid> (raw)
In-Reply-To: <f43fc5580710111226h51613fd8mc551ada410ac3cef@mail.gmail.com>
On Thu, 2007-10-11 at 22:26 +0300, Blue Swirl wrote:
> On 10/10/07, Fabrice Bellard <fabrice@bellard.org> wrote:
> > Thiemo Seufer wrote:
> > > Fabrice Bellard wrote:
> > >> J. Mayer wrote:
> > >>> Following the patches done for elfload32, it appeared to me that there
> > >>> were still problems that would prevent 32 bits executables to run on 64
> > >>> bits target in linux user mode emulation.
> > >>> [...]
> > >> Are you sure it is a good idea to try to add 32 bit executable support to a
> > >> 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux
> > >> syscall converter which would mean duplicating all the linux-user code of
> > >> the corresponding 32 bit target (think of ioctls with strutures, signals
> > >> frames, etc...).
> > >
> > > I would think this feature will be limited to platforms which can handle
> > > 32bit and 64bit binaries with a single personality.
> >
> > I am not sure it is a common case !
> >
> > However, I suggest to emulate a 32 bit user linux system with a 64 bit
> > guest CPU running in 32 bit compatibily mode. It would be useful to test
> > 64 bit CPUs in 32 bit compatibility mode. The only required modification
> > in linux user is to rename target_ulong so that it can have a different
> > size of the CPU word default size.
>
> I made a patch to rename target_ulong/long to abi_ulong/long and also
> add a new emulator target that uses the 32 bit ABI with 64 bit CPU.
>
> Some Sparc32 binaries run, others don't, possibly indicating bugs in
> the Sparc64 emulation!
>
> The patch is quite large because of the renaming, but this shouldn't
> have effect to any other target. Any comments?
Great !
The patch seems safe, at first look, then I noticed a few things that
are not correct or may be improved:
* In linux-user/main.c: PowerPC DCR access should keep using
target_ulong. This is a hardware bus, not an ABI dependent stuff. If a
32 bits cast is needed, it would be done in the micro-ops that handle
the DCR bus accesses.
* in linux-user/qemu.h: why is there still a OVERRIDE_ELF_CLASS
variable, when checking TARGET_ABI32 should be sufficient ? It seems to
me that having 2 defines which are, in fact, synonymous may be a source
of confusion.
* in configure: you also added a sparc64-softmmu target, which seems not
related with this particular patch.
* in configure: why add a specific TARGET_ABI32_DIR variable for that
case ? It seems to me that a TARGET_ABI_DIR variable could be useful for
all targets. Let me give an example: I want to add a ppcemb-linux-user
target, emulating a PowerPC 32 with 64 bits registers and SIMD
extensions but I don't want to duplicate the linux-user/ppc
subdirectory. Having a TARGET_ABI_DIR available for all targets would
solve my problem. In fact, even ppc and ppc64 could be merged... As you
need this feature in your case, I think it would be a good idea to add
it for all targets. And then, the kludge in Makefile.target could be
replaced by:
-CPPFLAGS+=-I$(SRC_PATH)/linux-user -I
$(SRC_PATH)/linux-user/$(TARGET_ARCH)
+CPPFLAGS+=-I$(SRC_PATH)/linux-user -I
$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)
which is simpler and easier to understand, imho.
--
J. Mayer <l_indien@magic.fr>
Never organized
next prev parent reply other threads:[~2007-10-11 22:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-10 7:42 [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets J. Mayer
2007-10-10 8:18 ` Fabrice Bellard
2007-10-10 16:09 ` Blue Swirl
2007-10-10 17:49 ` Thiemo Seufer
2007-10-10 18:40 ` Fabrice Bellard
2007-10-10 19:02 ` Blue Swirl
2007-10-10 21:51 ` J. Mayer
2007-10-11 15:17 ` Thiemo Seufer
2007-10-11 15:47 ` Blue Swirl
2007-10-11 16:00 ` Thiemo Seufer
2007-10-11 19:26 ` Blue Swirl
2007-10-11 22:00 ` J. Mayer [this message]
2007-10-12 16:21 ` Blue Swirl
2007-10-12 18:42 ` Thiemo Seufer
2007-10-12 19:37 ` Blue Swirl
2007-10-12 20:24 ` Thiemo Seufer
2007-10-10 16:01 ` Blue Swirl
2007-10-10 18:42 ` J. Mayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1192140040.9976.235.camel@rapid \
--to=l_indien@magic.fr \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.