On Sat, Feb 11, 2006 at 12:44:37 +0100, Julio M. Merino Vidal wrote:

> On Saturday 11 February 2006 12:18, Pavel Cahyna wrote:
> 
> > Why is it necessary to copy the symbol table somewhere? Can't you
> > leave it where it is?
> 
> Because the kernel needs a different format that the one passed in by
> Multiboot.  It needs a minimal ELF image that contains the symbol table
> (see the copy_syms function in multiboot.c) and then sets 'ssym' and
> 'esym' to the beginning and end of this image, respectively.  (It also
> expects it to be just after the kernel image, so that it is properly
> relocated.)
> 
> The restriction of it being just after the kernel image can be solved.
> But I'm not sure about the fact that the minimal ELF image needs to be
> contiguous in memory (between ssym and esym).  Who warrants that the
> memory before where GRUB put the symbol table is free?  (Because we'd
> need to write the ELF header there.)
> 
> Anyway, I'm sure there is a solution to avoid the copy.  But it already
> felt very complex when I wrote the code as is.

Admittedly, I haven't touched that code for quite a while, but iirc
the Elf header is only needed to find the location of symtab and
strtab sections.  The Elf header is discarded (overwritten when we
compact the symtab) immediately.

The code in addsymtab() currently assumes the Elf image is contiguous,
and that symtab comes before the strtab (hpcboot used to pass them in
different order, and the code to compact symtab section was happily
overwriting strtab).

I haven't looked at how GRUB passes symbol table, but I wonder
wouldn't it be easier to write alternative code that inits ksyms from
the grub symtab directly instead of constructing an Elf image to pass
to addsymtab.

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen