> > I'm running such a system for quite some time now.  It uses the
> symbols loaded
> > by the boot code for use with ddb and supplies an a.out file with zero-sized
> > text and data and these symbols as "/kern/kernel", i.e. in the kernfs
> > filesystem.
> 
> Admirably.

Hmm.  Probably not.  See below.

> There are 2 points I'm really interested how you managed them:
> - DDB "relocates" the symbol name offsets into absolute addresses.
>    The tools reading a.out expect offsets. Did you change DDB?

The truth is that I didn't even know that DDB did such things.  Since I don't
have any use for DDB, I didn't even look how it handles the symbol table.

One possible solution would indeed be to modify DDB to not change the symbol
table, but search it unmodified.  On the other hand, I wanted to copy the
symbol table into pageable memory anyway, in order to not occupy physical
memory if DDB isn't in use.  As I said in my previous post, this would require
some changes to the VM system however.

> - If additional symbol tables are loaded with LKMs (generally,
>   not aligned to pages), how ho you fake one big table? (This must
>   be mmap-able for nlist!)

Adding support for symbol tables of LKMs is a totally different problem.
And I cannot see a good reason to want this anyway.  The symbol table of the
current kernel is needed only for a few applications.

For one thing there are programs that want to poke around in the kernel data
structures, like e.g. ps, netstat, etc.  For these programs there is no need
to know about the additional symbols.

The other use of the kernel symbol table is for new LKMs.  It looks quite
questionable to me to link one LKM against another and use symbols from that.
It makes loading/unloading of LKMs nearly impossible due to unmanagable
interdependencies.  If one really wants to load one LKM that uses symbols
defined in another one (and I did this myself in the past), one should probably
know what to do and link against the result of the ld -A pass done during the
previous modload.

OK, I can see the possible desire to have the symbols of some LKM available
for some special investigation utility, but I'd argue that this is best handled
by using the symbols of the result of the ld -A pass here, too.

--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800