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

Re: [Xen-devel] [PATCH][ELF] Correct space calculation for symtab when BSD_SYMTAB=yes


  • To: Christoph Egger <Christoph.Egger@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Thu, 02 Aug 2007 09:49:57 +0100
  • Delivery-date: Thu, 02 Aug 2007 01:47:46 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfU4hopWODAgUDVEdy3iQAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH][ELF] Correct space calculation for symtab when BSD_SYMTAB=yes

On 2/8/07 09:03, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:

> If there is a string table for section headers, it also gets loaded.
> Therefore take it into account in size calculation for kernel symtab.

I don't see how this works. In fact the whole sstart,send calculation looks
broken. What do the virtual addresses of the symtab/strtab sections have to
do with their location in the final address space, after loading? And since
you pack the sections into the domain address space in
elf_xen_dom_load_binary(), should you not simply sum the sizes of the
sections, then sstart=virt_kend and send=sstart+size_sum, rather than taking
max(end addresses in elf image) minus min(start addresses in elf image).

Does the section-header string table have to be loaded, or is that just an
artefact of the loader code scanning for all SYMTAB/STRTAB? Shouldn't the
loader fix up e_shnum and symtab's sh_link in the Elf metadata that it
generates? Couldn't the loader just use the saved elf->sym_tab and
elf->sym_strtab to directly find the interesting two sections, rather than
needing to do yet another full scan?

> Keir: Can you also apply changeset 15672 and this patch
> to Xen 3.1-stable, since these fixes an regression for Xen 3.1, please?

I don't think so!

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.