On Thu, 10 Sep 1998, der Mouse wrote:

 * >> This - or something like it - has been discussed before.  The
 * >> biggest problem with it is that what most programs want from /netbsd
 * >> is the symbol table, and that isn't always loaded into core.
 * > Programs that want the symbol table get it by running namelist not
 * > looking in core.
 * 
 * Well, yeah.  My point is that for /kern/kernel to be useful, it has to
 * provide a symbol table for nlist() to use, and for that, it needs to
 * have the symbols available to it in the first place.
 * 
 * >> (Indeed, unless you have ddb on, I think it usually isn't.)
 * > Symbols are loaded for ddb but only ddb gets to use them.  They are
 * > not currently exported.
 * 

Here's a thought:  The running kernel wouldn't need to know its own
name.  Just have it load the symbols into core at load time, then
have it dump out the symbol in table form after coming up multi-user
and free the memory (play some games with upper core or something,
I don't know), perhaps by a savestab command (similar to savecore
(yes,yes,yes, don't bother me with semantic differences here)).

And of course, if you don't make it to multi-user mode, the symbols
are still in core.

Just a thought; I don't know that it would justify adding a system
call or something to the sysctl interface, but it _would_ solve our
problems, although a debugging symbol table does seem a bit nontrivial
to keep in core :-(.

Example:

# savestab -v /kern.syms
/kern.syms: Read-only filesystem
No symbols saved; table remaining resident
# mount -u /
# savestab -v /kern.syms
Saving symbol table...4826 symbols saved to /kern.syms
Symbol table flushed from core
# 

And I think it WOULD require a special system call to facilitate 
this.

But as I said, it's just a thought.  Any better ideas?

...any takers, if not?


				--*greywolf;
--
Friends don't let friends use Microsoft.