From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvHyp-0007C5-4k for qemu-devel@nongnu.org; Wed, 08 Feb 2012 19:35:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvHyn-0005ys-Ni for qemu-devel@nongnu.org; Wed, 08 Feb 2012 19:35:19 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:60023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvHyn-0005yg-FE for qemu-devel@nongnu.org; Wed, 08 Feb 2012 19:35:17 -0500 From: Paul Brook Date: Thu, 9 Feb 2012 00:35:11 +0000 References: <87y5sdejnb.fsf@frosties.localnet> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202090035.12216.paul@codesourcery.com> Subject: Re: [Qemu-devel] Support for multiboot images in elf64 (EM_X86_64) format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Stefan Hajnoczi , Goswin von Brederlow > > starting your own toy kernel is a fun thing to do and there are many > > tutorials out there on how to do it. Unfortunately when one wants to > > write a kernel in 64bit it becomes much harder because one can't > > compile 64bit code as elf32 image and converting a elf64 image to > > elf32 format is a major hassle and looses debug information and symbols. So just have two versions of your image: - The elf64 image that has debug info, symbols, etc. Point gdb at this. - An elf32 image that you give to the bootloader (in this case kvm) Generating the latter from the former is a trivial objcopy invocation. The bootloader variant only needs enough information to get the loadable sections into memory. We don't care about non-resident clutter like debug info or symbols. Anything that cares about those will be using the full elf64 image. This is all standard practice. I don't think I've never actually used a system where the image loaded by the target is the same file as the one that comes out of the linker and is used by the debugger. > Yes, this is why I asked about support in other software. If each > bootloader implements a different custom method then it will be a pain > to run your binary on real hardware in the future. It's worth at > least checking their source first - maybe there is already a similar > code path that we can be compatible with, hence making life easier for > developers who want to play with 64-bit payloads in multiboot > executables. The whole idea of entering a 64-bit image in 32-bit mode seems distinctly sketchy. Surely it'd make more sense to define a 64-bit multiboot variant and do the job properly. Paul