Re: Kernel section info.

[Kurt Skauen]

OKUJI Yoshinori <address@hidden> writes:

> 
> From: Kurt Skauen <address@hidden>
> Subject: Kernel section info.
> Date: 31 Oct 2000 19:50:57 +0100
> 
> > How do I get information about the kernel image after the kernel is
> > booted? I tried to read the symbol information in the boot info
> > structure passed to the kernel, but the MB_INFO_ELF_SHDR flag is never
> > set, and as far as I can see the section info is never initialized in
> > GRUB. How am I supposed to find information about the kernel image?
> 
>   There is no way to pass the information to a kernel at the moment,
> as that is not implemented yet.
> 
> > The minimum info I need is the size of the kernel, and preferrably the
> > symbol table. How is this solved by other ELF kernels?
> 
>   Normally, ELF kernels use the symbols `_start' and `_end', to find
> out its own size. AFAIK, few ELF kernels really use symbol tables.

I found the _end symbol and that solved the size problem, but I whould
still like to have the symbols for debugging purposes. I use symbol
tables in the AtheOS kernel to be able to export functionality to
loaded device driver. The kernel have a manually assambled symbol
table of exported symbols so it is not critical, but it whould be nice
to have the full symbol table to make kernel stacktraces a bit more
informative.

Is there any plans for implementing this? And if so, is there an
estimate for when it might be done?

> > I also have some questions regarding the boot-module addresses. I
> > noticed that the first boot-module are located directly after the
> > kernel, and that each module is packed together. This is all nice, but
> > I can't find this specified in the MultiBoot specification. Can I
> > depend on this layout? Or can I risk getting another layout by later
> > versions of GRUB or by other MultiBoot compliant boot-loaders? Like
> > finding boot modules below 1M?
> 
>   No, yes and yes. You are responsible for relocating your modules
> appropriately, as long as you stick to the Multiboot Specification
> 0.6. It says that a Multiboot boot loader doesn't interpret the format
> of a module and it doesn't specify how to load modules. This might
> change in a future version of the Multiboot Specification.

Maybe it whould be a good idea to have this defined a bit more rigid?
Forcing the current layout might be a bit to strict, but at least
define that the boot-module list should be sorted on module locations
whould IMHO be a good idea. That whould make it much easyer to avoid
trashing the modules before proper memory managment is initialized.
And it whould be much easyer to implement this in the boot loader than
to sort it later in the kernel.

-- 
Kurt Skauen. ( http://www.atheos.cx/ )

"There are two kinds of people, those who do the work and those who take
credit. Try to be in the first group, there is less competition there." __
Indira Gandhi