All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Paul Brook <paul@codesourcery.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	qemu-devel@nongnu.org, Goswin von Brederlow <goswin-v-b@web.de>
Subject: Re: [Qemu-devel] Support for multiboot images in elf64 (EM_X86_64) format
Date: Thu, 09 Feb 2012 16:38:50 +0100	[thread overview]
Message-ID: <87zkcsnhit.fsf@frosties.localnet> (raw)
In-Reply-To: <201202091336.36127.paul@codesourcery.com> (Paul Brook's message of "Thu, 9 Feb 2012 13:36:35 +0000")

Paul Brook <paul@codesourcery.com> writes:

>> Paul Brook <paul@codesourcery.com> writes:
>> >> > 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.
>> 
>> Is it? I tried for a while and couldn't figure it out. I checked how
>> linux does it and it does quite a dance to achieve it.
>
> "objcopy -I elf64-x86-64 -O elf32-i386 64.elf 32.elf" worked for me.  
> Relocations get a bit confused, but you shouldn't have relocations in your 
> multiboot images to start with.

Why no relocations? Isn't exactly that the advantage of building an elf
image, that you can build a relocatable image?

I do remeber getting errors because x86_32_RELOC or something couldn't
be mapped to elf32-i386 output format. Can't reproduce it now
though. Your line above seems to work on my minimal hello-world kernel.

> Linux is a bit special because it has its own boot protocol. AFAIK it can't be 
> used as a regular multiboot image directly, you need to add a wrapper (i.e. a 
> secondary bootloader).
>
> Paul

I noticed. I quickly gave up using the linux kernel and build system as
reference for a simple toy kernel.

MfG
        Goswin

  reply	other threads:[~2012-02-09 15:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-04 17:38 [Qemu-devel] Support for multiboot images in elf64 (EM_X86_64) format Goswin von Brederlow
2012-02-06 12:38 ` Stefan Hajnoczi
2012-02-08  9:53   ` Goswin von Brederlow
2012-02-08 11:30     ` Kevin Wolf
2012-02-08 12:06     ` Stefan Hajnoczi
2012-02-09  0:35       ` Paul Brook
2012-02-09 13:07         ` Goswin von Brederlow
2012-02-09 13:36           ` Paul Brook
2012-02-09 15:38             ` Goswin von Brederlow [this message]
2012-02-09 16:01               ` Paul Brook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zkcsnhit.fsf@frosties.localnet \
    --to=goswin-v-b@web.de \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.