qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] How to make ELF headers/symbol sections available for m


From: Kevin Wolf
Subject: Re: [Qemu-devel] How to make ELF headers/symbol sections available for multiboot?
Date: Mon, 31 Jul 2017 13:27:20 +0200
User-agent: Mutt/1.8.3 (2017-05-23)

Am 30.07.2017 um 23:42 hat Eduardo Habkost geschrieben:
> CCing Alex, the original author of load_multiboot(), and Kevin,
> who touched multiboot code recently.

For some values of "recently". :-)

> On Fri, Jul 28, 2017 at 02:28:34PM -0700, Anatol Pomozov wrote:
> > Hi
> > 
> > I am looking at x86 multiboot code and trying to add "ELF section
> > header" info feature. This will let target to learn more about booted
> > binary and its sections.
> 
> Are there existing OSes that use that information?

You mean, like, relevant ones? I've used this feature before myself and
I think I've seen others use it for OSes that will never spread much
beyond their own computer, but from the more popular OSes that implement
Multiboot, it seems that at least NetBSD and the Hurd (or really GNU
Mach) are making some use of it.

> > I have a draft here
> > https://github.com/anatol/qemu/commit/ad943a6eb78feee048b6bb2a1e5f49f5b686e24c
> > 
> > My understanding is that qemu multiboot loads only TEXT/BSS/DATA
> > sections. Other stuff like symbols sections and ELF headers are not
> > available for target.
> > 
> > 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?

I think I would have done the same.

> >  - 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?

I think that the functions in include/hw/elf_ops.h (specifically
load_symbols32) might already do most of what you need. This file is
just a bit hard to navigate because the function names are composed by
preprocessor macros.

In the end it seems to fill a global variable struct syminfo *syminfos.
Maybe you can get the information you need from there, though it seems
to have been processed (keep only function symbols, sort the list). It
would be more correct to provide the original symbol table.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]