All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] linux-user: Remove ELFLOAD32.
Date: Sat, 24 Apr 2010 17:36:46 -0700	[thread overview]
Message-ID: <4BD38E9E.3050409@twiddle.net> (raw)
In-Reply-To: <u2sf43fc5581004231136y3f18e610u99be0775a0962fd3@mail.gmail.com>

On 04/23/2010 11:36 AM, Blue Swirl wrote:
> On 4/23/10, Richard Henderson <rth@twiddle.net> wrote:
>> The ABI-specific types used by linux_binprm and image_info
>>  are different after forcing TARGET_ABI32 on.  Which means
>>  that the parameters that load_elf_binary_multi sees are not
>>  those that loader_exec passed.  This is inherently broken
>>  and is more trouble than it's worth fixing.
> 
> Nack. How is this inherently broken?

sizeof(abi_ulong) is different in elfload32.c and linuxload.c,
which means the two files cannot communicate with any type
affected by this change.  Which is both linux_binprm and image_info.

> The problem that elfload32 solves is that the CPU is 64 bit, but the
> ABI and the binaries loaded are still 32 bits. It works nicely for
> sparc32plus binaries (ELFCLASS32, but only for V9 CPUs).

And yet we have a separate sparc32plus-linux-user/qemu-sparc32plus
binary that does that job.

Do we really need qemu-sparc64 to do both jobs?  Because it doesn't.
The only thing that happens is that qemu crashes immediately because
it sees linux_binprm.e_gid at the offset it expects to see
linux_binprm.argc, and fails to copy gid=rth(5000) entries from the
argv array.


r~

  reply	other threads:[~2010-04-25  0:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23  0:24 [Qemu-devel] [PATCH] linux-user: Remove ELFLOAD32 Richard Henderson
2010-04-23 18:36 ` [Qemu-devel] " Blue Swirl
2010-04-25  0:36   ` Richard Henderson [this message]
2010-04-25 15:08     ` Blue Swirl

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=4BD38E9E.3050409@twiddle.net \
    --to=rth@twiddle.net \
    --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.