Hi Adam Do these arguments sound reasonable to apply the patch?
On Thu, Jun 8, 2017 at 2:07 PM, Anatol Pomozov <anatol.pomo...@gmail.com> wrote: > +reply-all > > On Thu, Jun 8, 2017 at 1:41 PM, Adam Lackorzynski > <a...@os.inf.tu-dresden.de> wrote: >> >> On Tue Jun 06, 2017 at 21:41:48 -0700, Anatol Pomozov wrote: >>> It is possible to create a 64 bit elf image that has valid multiboot header. >>> qemu should be able to boot such images. >> >> But this 64bit image actually starts with 32bit code, right? > > Correct. The very first part of the startup code has to be 32bit. > After it sets "long mode" it can use 64bit instructions. To make sure > that the preamble has only 32bit instructions one have to use asm > directive such as ".code32". > > Here is an example from LitleKernel sturtup code: > > https://github.com/littlekernel/lk/blob/master/arch/x86/64/start.S#L50 > > .code32 tells assembler to treat following text as 32 bit code. And > later when it jumps into "long mode" > > https://github.com/littlekernel/lk/blob/master/arch/x86/64/start.S#L214 > one can use 64bit code. > >> So it's a 32bit program and the check verifies that this is the case. > > While preamble have to contain 32 only instructions the rest of the > image can perfectly contain 64bit code. Right now 64bit binary cannot > be run with "qemu-system-x86_64 -kernel". But the same binary runs > fine if packed with GRUB as iso. > > I tried to hack around this restriction by adding > "OUTPUT_FORMAT(elf32-i386)" to the linker file and compiling project > with 64bit support. But GNU ld program crashed at Ubuntu 14.04. It > means not that many people use this code path. GNU ld compiled from > HEAD does not have this problem but now GDB is confused by the fact > that ELF contains 64bit code while header reports i386. > > Practically there is no reason for this check as it prevents running > 64bit binaries with "qemu-system-x86_64 -kernel".
