From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IcC49-0003u1-Cs for qemu-devel@nongnu.org; Sun, 30 Sep 2007 23:35:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IcC46-0003tT-UJ for qemu-devel@nongnu.org; Sun, 30 Sep 2007 23:35:28 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IcC46-0003tQ-OE for qemu-devel@nongnu.org; Sun, 30 Sep 2007 23:35:26 -0400 Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IcC45-0007uk-VS for qemu-devel@nongnu.org; Sun, 30 Sep 2007 23:35:26 -0400 Date: Mon, 1 Oct 2007 04:35:22 +0100 From: Thiemo Seufer Subject: Re: [Qemu-devel] RFC: cleanups in ELF loader Message-ID: <20071001033522.GG13317@networkno.de> References: <1191116355.29900.86.camel@rapid> <20070930133839.GD13317@networkno.de> <1191164963.29900.141.camel@rapid> <1191206541.29900.166.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1191206541.29900.166.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 J. Mayer wrote: > On Sun, 2007-09-30 at 17:09 +0200, J. Mayer wrote: > > On Sun, 2007-09-30 at 14:38 +0100, Thiemo Seufer wrote: > > > J. Mayer wrote: > > > > Following what I've done in the syscalls emulation routines, it appeared > > > > to me that there seems to be a lot of confusions between host and target > > > > long in the ELF loader. > > > > > > But the ELF fields are tied to the ELFCLASS of the supported ABI, not to > > > the register width of the machine emulation. If anything they should > > > become the ELF types. > > > > > > (Your approach will e.g. break down for MIPS N32, where "long" is smaller > > > thant the register width, and the ABI uses ELFCLASS32.) > > > > OK, I will try to rework this. > > I did check in the linux kernel and it appears that all variables I > changed from unsigned long to target_ulong seem to be unsigned long in the > kernel. This looks fine for me as they are addresses in the process virtual address space, > so they should fit in a target_ulong, whatever the target registers size could be. As long as eventual sign extensions are done properly this is ok. (Some places in the kernel have casts to elf_greg_t for that purpose.) > What seems bugged to me (but I did not make any change in that part) is > the auxiliary vectors generation. This seems to me to be the only place > where Linux explicitelly uses elf_addr_t so Qemu should do the same. > Then, it seems that my patch is not so bad and should not break anything > but is not complete as it does not fix the auxiliary vectors. > > Do you agree with this, or did I miss something else ? The kernel loader (fs/binfmt_elf.c) is somewhat geared towards single ABI architectures. PowerPC, MIPS, SPARC etc. have all their own kludge (in arch/$ARCH/kernel/binfmt_elf*.c) to redefine some essential bits and then #include fs/binfmt_elf.c. The whole thing looks a bit scary, I'm not sure we should import it in Qemu. OTOH it is generally a good idea to stay in sync with the kernel implementation. Thiemo