From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH][ELF] Correct space calculation for symtab when BSD_SYMTAB=yes Date: Thu, 02 Aug 2007 09:49:57 +0100 Message-ID: References: <200708021003.54137.Christoph.Egger@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200708021003.54137.Christoph.Egger@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christoph Egger , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 2/8/07 09:03, "Christoph Egger" 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