From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RackG-000878-5Y for qemu-devel@nongnu.org; Tue, 13 Dec 2011 19:30:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RackF-0000Fn-6N for qemu-devel@nongnu.org; Tue, 13 Dec 2011 19:30:52 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:43042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RackF-0000FL-20 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 19:30:51 -0500 From: Paul Brook Date: Wed, 14 Dec 2011 00:30:44 +0000 References: <1323725761-5629-1-git-send-email-agraf@suse.de> <201112131631.28969.paul@codesourcery.com> <218892C4-3E2C-4278-B0E9-D9FF61E2FCB9@suse.de> In-Reply-To: <218892C4-3E2C-4278-B0E9-D9FF61E2FCB9@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112140030.45213.paul@codesourcery.com> Subject: Re: [Qemu-devel] [PATCH] PPC: Fix linker scripts on ppc hosts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Riku Voipio , "dvaleev@suse.com" , "qemu-devel@nongnu.org" , Richard Henderson > >>>>> When compiling qemu statically with multilib on PPC, we hit the > >>>>> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49 > >>>>> is fixing. Do the same here. > >>>> > >>>> How many of these ld files can we get rid of if we use -Ttext-segment > >>>> instead? Generally all we're really caring about is moving the program > >>>> base around so that it doesn't conflict with the address space we want > >>>> to use for the client. > >>> > >>> Now that we have the automatic GUEST_BASE stuff you shouldn't need to > >>> do either. > >> > >> If it was working, yes :) > > > > What doesn't work? I put a fair amout of effort into making it > > automatically pick a sensible value. If there's some reason that won't > > work then you probably want to be using -R. > > IIRC mmap'ing files would break with 32-on-64, but I'd have to check up on > the details. I ended up passing MAP_32BIT to all linux-user mmap calla for > 32-on-x86_64, but that doesn't work with -R. Hmm, I thought we'd fixed that. It's the reason h2g_valid exists. Either way it should definitely work with -R. I specifically added that to avoid problems with the host mmap picking inconvenient addresse. MAP_32BIT is an unconsionable hack, and doesn't exist on other 64-bit hosts. Paul