From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPN8g-00037h-Vj for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:23:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPN8g-00036v-Ga for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:23:58 -0500 Received: from [199.232.76.173] (port=37349 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPN8g-00036e-1M for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:23:58 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]:11276) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPN8f-0002xs-HI for qemu-devel@nongnu.org; Tue, 20 Jan 2009 15:23:57 -0500 Received: by fg-out-1718.google.com with SMTP id 19so1659087fgg.8 for ; Tue, 20 Jan 2009 12:23:54 -0800 (PST) Message-ID: <761ea48b0901201223q628928e7qe586c42e147a7b6c@mail.gmail.com> Date: Tue, 20 Jan 2009 21:23:44 +0100 From: "Laurent Desnogues" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Qemu-devel] User mode issue for loading 32-bit ELF on 64-bit guest processor Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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