qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: Peter Maydell <peter.maydell@linaro.org>,
	Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] How to make ELF headers/symbol sections available for multiboot?
Date: Mon, 31 Jul 2017 06:04:59 -0700	[thread overview]
Message-ID: <19ee3dfd-dd1c-191d-14fb-a44058c8ccb6@twiddle.net> (raw)
In-Reply-To: <CAFEAcA8N_JyMVtLPdSFEUUgmJ0OG6AbHuD=5KhO8kv3fJDLwGw@mail.gmail.com>

On 07/31/2017 01:50 AM, Peter Maydell wrote:
> On 28 July 2017 at 22:28, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
>> So I need to perform 2 things:
>>
>>   - Load ELF section headers into target's memory. I did by appending
>> additional space to mbs.mb_buf and copying header data. Is it the best
>> way to do?
>>
>>   - Next I need to load other ELF sections such as symbols (e.g.
>> .shstrtab) that store section names. What is the best way to do in
>> multiboo.c code? Would it make sense to load all ELF sections?
> 
> This seems a bit odd, because in general an ELF loader should
> not care at all about sections and the section header. It
> should only need to look at the program header, which defines
> which segments to load. If the guest binary needs some things
> to be loaded then I would expect that it is the job of the linker
> that produces the guest binary to make sure those things are in
> segments which are marked as LOAD.

Agreed.  If you're touching ELF sections, then I think you're missing the point 
of the ELF program header entirely.  If you write your own linker script, you 
have complete control of the ELF PHDR, and can arrange for anything you like to 
be loaded.


r~

      reply	other threads:[~2017-07-31 13:05 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
2017-07-31  8:50 ` Peter Maydell
2017-07-31 13:04   ` Richard Henderson [this message]

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=19ee3dfd-dd1c-191d-14fb-a44058c8ccb6@twiddle.net \
    --to=rth@twiddle.net \
    --cc=anatol.pomozov@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).