[ On Mon, November 24, 1997 at 11:43:17 (-0500), Gordon W. Ross wrote: ]
> Subject: Re: And just how big can it be? (Sun3/50 kernels..)
>
> > From: woods@most.weird.com (Greg A. Woods)
> >
> > Remember that stripping an object doesn't make its load image any
> > smaller.
> 
> True, but this case is unusual, because the kernel boot loader
> copies the symbols into memory after BSS, and the kernel saves
> the symbol table if DDB is included in the configuration.

Hmmm..... That's interesting.  I hadn't realized that, but I guess given
the potentially shaky position the DDB could find itself in this is the
only way it can possibly have access to the symbol table.  Is this
documented anywhere?

Is this information also included in the kernel dump and thus saved by
savecore?  (I assume so since it seems savecore does the right thing and
squirrels away a copy of all of RAM, which leaves all processes that
were on the swap device that's usually the dump device too out to dry.)

Is this information available after the fact to 'gdb -k' or its new
moral equivalent?  If so I guess that means I don't have to remember
which kernel goes with which savecore, right?  But I doubt it's so....

Savecore doesn't seem to be smart enough to know when it might not need
to copy the kernel yet I can't quite understand why it's never copied
the kernel for me even after apparently successfully copying the core
image from the dump device.

As per my PR (4511 I think -- I can't connect to www.netbsd.org just now
to check) on savecore I don't think it should exit after the warnings
about possibly incomplete saves (i.e. after the err2: label), but rather
just continue on and finish saving the system image (kernel) too.

Is there anything else that's different or unique about the DDB and the
savecore process on NetBSD/sun3?

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>