From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IeXrC-0000vV-Vq for qemu-devel@nongnu.org; Sun, 07 Oct 2007 11:15:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IeXrB-0000vJ-6a for qemu-devel@nongnu.org; Sun, 07 Oct 2007 11:15:50 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IeXrB-0000vG-0L for qemu-devel@nongnu.org; Sun, 07 Oct 2007 11:15:49 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IeXrA-0007RC-QO for qemu-devel@nongnu.org; Sun, 07 Oct 2007 11:15:49 -0400 Received: by nf-out-0910.google.com with SMTP id 30so842610nfu for ; Sun, 07 Oct 2007 08:15:47 -0700 (PDT) Message-ID: Date: Sun, 7 Oct 2007 18:15:47 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user In-Reply-To: <1191768541.9976.23.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1191765716.9976.17.camel@rapid> <1191768541.9976.23.camel@rapid> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org On 10/7/07, J. Mayer wrote: > On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote: > > On 10/7/07, J. Mayer wrote: > > > On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote: > > > > Hi, > > > > > > Hi, > > > > > > > This patch adds support for loading a 32 bit ELF file in the 64 bit > > > > user mode emulator. This means that qemu-sparc64 can be used to > > > > execute 32 bit ELF files containing V9 instructions (SPARC32PLUS). > > > > This format is used by Solaris/Sparc and maybe by Debian in the > > > > future. > > > > > > > > Other targets shouldn't be affected, but I have done only compile > > > > testing. Any comments? > > > > > > The idea of loading 32 bits executables on 64 bits target seems great. > > > Then, I got two remarks about this patch: > > > - it seems that it does not take care about my patch. As I was to commit > > > it today, I wonder if I still should do it. But then, your patch lacks > > > some bugifxes (start_data not properly computed and TARGET_LONG_BITS != > > > HOST_LONG_BITS problems). > > > > Well, I thought that you had already applied the patch. > > OK, do you agree that I apply it and you take the changes in yours ? Yes, the patch looks OK (haven't tested it) and if something still breaks, we can fix it. > > > > > - it seems that quite all the ELF loader code is affected by your patch. > > > I think (maybe too naively) that adding functions to read the ELF infos > > > should be sufficient, ie add a read_elf_ehdr, ..., functions and a few > > > patches in the create_elf_table function. Then, all informations nedded > > > to load a 32 bits executable can be kept into the 64 bits structures. As > > > the kernel does not duplicate the code to handle this case, I think Qemu > > > loader should be kept as simple as the kernel one, and the elfload_ops.h > > > seems to me to be useless. In fact, Qemu loader could (should ?) even be > > > the same code than the kernel one with just a few helpers for endianness > > > swaps and the needed fixes to avoid confusions between host_long and > > > target_long... > > > > Sparc64 Linux handles 32 bit ELF binaries (both V8 = 32 bit insn and > > V9 = 64 bit insn) in arch/sparc64/kernel/binfmt_elf32.c, which > > #includes fs/binfmt_elf.c. > > 64 bit V9 binaries are handled by fs/binfmt_elf.c. > > > > In Qemu we can't do it like this, because V9 instruction emulator must > > be used to handle also the 32 bit ELF. The same effect could be > > achieved in Qemu for example by adding new file elfload_32.c, which > > would include elfload.c after defining the ELF classes etc. This would > > need some rearranging in elfload.c so that the ELF parameters can be > > overridden. I'm not sure this would be much cleaner than my version > > using glue(). > > OK, then if the kernel duplicates the compiled code, it means that this > way of doing might be the proper one. Couldn't you do something closest > to what the kernel do, ie moving the per target definitions located at > the top of elfload.c somewhere else and add a elfload_32.c file that > would include elfload.c redefining all needed variable types, ... ? This > just to keep the code as close as possible to the kernel one, even if it > functionnaly changes nothing... I'll try if that works. It could be a better approach after all.