qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Laurent Desnogues" <laurent.desnogues@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] User mode issue for loading 32-bit ELF on 64-bit guest processor
Date: Tue, 20 Jan 2009 21:23:44 +0100	[thread overview]
Message-ID: <761ea48b0901201223q628928e7qe586c42e147a7b6c@mail.gmail.com> (raw)

Hello,

while playing with sparc64 Linux user mode emulation, I tried
to run a 32-bit v8plus executable;  this may not work according
to Blue Swirl, but that's not the issue I had.

Currently elfload32.c forces the definition of TARGET_ABI32
before including elfload.c.  This notably results in abi_ulong
being forced as a 32-bit integer.  In turn this will change some
structure layouts such as linux_binprm and image_info which
are parameters of load_elf_binary/load_elf_binary32.  But
linuxload.c/loader_exec uses the standard 64-bit integer for
defining abi_ulong.  In the end this segfaults when accessing
fields of linux_binprm when trying to load a 32-bit ELF.

I am not sure what is the cleanest way to fix that problem.  As
a quick hack I just inserted uint32_t fields after each abi_ulong
field in linux_binprm and image_info structures when
TARGET_ABI32 is defined (I know this is not generally correct,
it was just a way to check my understanding was right).

Blue Swirl proposed to use accessors for these structures
while I proposed to use a new abi_ulong-like type that would
be the same no matter whether TARGET_ABI32 is defined or
not.  As I am not sure there aren't some other structures that
would need such a type, I think my proposal is less intrusive.
The drawback is that it would introduce a new type and we
already have many such *_ulong types :-)

What do people think?


Laurent

             reply	other threads:[~2009-01-20 20:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-20 20:23 Laurent Desnogues [this message]
2009-01-21  5:40 ` [Qemu-devel] User mode issue for loading 32-bit ELF on 64-bit guest processor Paul Brook
2009-01-21  7:06   ` Laurent Desnogues

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=761ea48b0901201223q628928e7qe586c42e147a7b6c@mail.gmail.com \
    --to=laurent.desnogues@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).