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

Hi!

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

Also there is no need to call elf_set_verbose() a second time
after elf_init() (First call happens within elf_init()).

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

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?


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


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

On 2/8/07 09:03, "Christoph Egger" <Christoph.Egger@amd.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 02 August 2007 10:49:57 Keir Fraser wrote:
> On 2/8/07 09:03, "Christoph Egger"
<Christoph.Egger@amd.com> 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.
Basically, I do it the same way as Xen 3.0.4 did: First calculate the space
you need, then fill the space with ELF header, ELF section headers and
the symbol and string sections itself.
> In fact the whole sstart,send calculation looks broken.
Well, I did it analogous to elf_parse_binary() how it calculates the space
for phdr.
> 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).
You''re right. Attached is a patch, which does it that way.

(Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>)

Oh and c/s 15677 in the staging tree removes the wrong elf_set_verbose() call.
Without it, you will never see the elf_msg() in elf_init().
The correct duplicate to remove is the one right after the use of elf_init(). 
My patch removes it.
> 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?
I think, Xen should just pass to Dom0 what it has and let Dom0 decide what
it wants to use.
> 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?
It needs to go through it, because it must adjust the sh_offset accordingly
in the section headers.
> > 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!
I *do* think so :-) Look (I marked the most interesting lines with an arrow):


With Xen 3.0.4 I get this:

[...]
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch input to
Xen).
(XEN) Freed 92kB init memory.
Loaded initial symtab at 0xc09d7ad8, strtab at 0xc0a38cb4, # entries 23398 
<Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 4.99.26 (XEN3_DOM0) #70: Wed Jul 25 15:54:08 UTC 2007
        root@tulln:/usr/src/sys/arch/i386/compile/XEN3_DOM0
[...]

With Xen 3.1 I get this:

[...]
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch input to
Xen).
(XEN) Freed 92kB init memory.
[ Kernel symbol table missing! ]                                      
<Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 4.99.26 (XEN3_DOM0) #74: Wed Aug  1 10:57:21 UTC 2007
        root@tulln:/usr/src/sys/arch/i386/compile/XEN3_DOM0
[...]


and in -unstable (with my patches) I get this:

[...]
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch input to
Xen).
(XEN) Freed 108kB init memory.
Loaded initial symtab at 0xc09decd8, strtab at 0xc0a4001c, # entries 23398 
<Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 4.99.26 (XEN3_DOM0) #74: Wed Aug  1 10:57:21 UTC 2007
        root@tulln:/usr/src/sys/arch/i386/compile/XEN3_DOM0
[...]




Christoph


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


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

On 2/8/07 13:26, "Christoph Egger" <Christoph.Egger@amd.com>
wrote:
>> 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).
> 
> You''re right. Attached is a patch, which does it that way.
Please try changeset 15679 in the -unstable staging tree. It''s less
code and
also fixed up to work with the domU domain builder too. Except it''s not
actually been tested with a bsd_symtab guest kernel. It shouldn''t need
more
than a few lines of fixing to get it working though, if that.

 -- Keir


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

On Thursday 02 August 2007 15:21:34 Keir Fraser wrote:
> On 2/8/07 13:26, "Christoph Egger"
<Christoph.Egger@amd.com> wrote:
> >> 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).
> >
> > You''re right. Attached is a patch, which does it that way.
>
> Please try changeset 15679 in the -unstable staging tree. It''s
less code
> and also fixed up to work with the domU domain builder too. Except
it''s not
> actually been tested with a bsd_symtab guest kernel. It shouldn''t
need more
> than a few lines of fixing to get it working though, if that.
>
>  -- Keir
I tested this both with a Dom0 and DomU guest domain. It works!
Thanks a lot.


Christoph



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy



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