From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5pqO-0004wI-49 for qemu-devel@nongnu.org; Sat, 24 Apr 2010 20:37:08 -0400 Received: from [140.186.70.92] (port=54416 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5pqL-0004wA-GG for qemu-devel@nongnu.org; Sat, 24 Apr 2010 20:37:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5pqK-00038C-67 for qemu-devel@nongnu.org; Sat, 24 Apr 2010 20:37:05 -0400 Received: from mail-pv0-f173.google.com ([74.125.83.173]:54656) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5pqJ-000384-I7 for qemu-devel@nongnu.org; Sat, 24 Apr 2010 20:37:03 -0400 Received: by pvg4 with SMTP id 4so16454pvg.4 for ; Sat, 24 Apr 2010 17:37:02 -0700 (PDT) Sender: Richard Henderson Message-ID: <4BD38E9E.3050409@twiddle.net> Date: Sat, 24 Apr 2010 17:36:46 -0700 From: Richard Henderson MIME-Version: 1.0 References: <20100423002659.199E0101C@are.twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] linux-user: Remove ELFLOAD32. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org On 04/23/2010 11:36 AM, Blue Swirl wrote: > On 4/23/10, Richard Henderson 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~