From: Kevin Wolf <kwolf@redhat.com>
To: Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] How to make ELF headers/symbol sections available for multiboot?
Date: Tue, 1 Aug 2017 16:06:39 +0200 [thread overview]
Message-ID: <20170801140639.GD4257@localhost.localdomain> (raw)
In-Reply-To: <CAOMFOmUwi+jF4w7ve4iV_rrPt2uAqZDe6PMZ0r0W047yjFi-gw@mail.gmail.com>
Am 31.07.2017 um 19:21 hat Anatol Pomozov geschrieben:
> ELF sections info is needed for an OS to map address space properly.
>
> I do not know much about production-grade OS but multiboot protocol is
> quite popular among newly created and hobby OS. Multiboot provide some
> useful information that need to be found somewhere else (e.g. by
> requesting info from BIOS).
>
> Here is an example of Phil's Rust OS that uses multiboot to read ELF
> section information. https://os.phil-opp.com/allocating-frames/ They
> use GRUB that loads all ELF sections into memory and provides ELF info
> via multiboot structure.
>
> It is interesting to see how LittleKernel tries to find the sections
> information by using _start/_end markers in their linker script
> https://github.com/littlekernel/lk/blob/master/arch/x86/64/kernel.ld
> And while it works, in fact it just tries to recover ELF sections
> information. And that is why I think it would be more useful if qemu
> implemented ELF sections feature from Multiboot.
Why would you calculate something at runtime by looping through the
section table when you could do this once and for all at link time?
This sounds completely inefficient and is probably a bad idea. What
littlekernel does is pretty much the standard way to do things.
This doesn't mean that the Multiboot feature is useless, but just that
the real use cases are different. Having symbol names in stack traces
is one of them.
And anyway, the feature is in the spec and QEMU implements this spec, so
I think we don't have to discuss whether having the feature would be
good. It just needs a clean implementation.
Kevin
next prev parent reply other threads:[~2017-08-01 14:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 21:28 [Qemu-devel] How to make ELF headers/symbol sections available for multiboot? Anatol Pomozov
2017-07-30 21:42 ` Eduardo Habkost
2017-07-31 6:25 ` Alexander Graf
2017-07-31 11:27 ` Kevin Wolf
2017-07-31 17:21 ` Anatol Pomozov
2017-07-31 18:20 ` Richard Henderson
2017-08-02 22:00 ` Anatol Pomozov
2017-08-02 22:45 ` Richard Henderson
2017-08-03 8:39 ` Kevin Wolf
2017-08-04 4:53 ` Anatol Pomozov
2017-08-08 15:04 ` Kevin Wolf
2017-08-17 20:54 ` Anatol Pomozov
2017-09-11 18:48 ` Anatol Pomozov
2017-09-11 18:49 ` Anatol Pomozov
2017-08-01 14:06 ` Kevin Wolf [this message]
2017-07-31 8:50 ` Peter Maydell
2017-07-31 13:04 ` Richard Henderson
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=20170801140639.GD4257@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=agraf@suse.de \
--cc=anatol.pomozov@gmail.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.