Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Apr 1999 14:45:24 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Greg Lehey <grog@lemis.com>
Cc:        Archie Cobbs <archie@whistle.com>, Christopher Michaels <ChrisMic@clientlogic.com>, gjb@comkey.com.au, questions@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject:   Re: Debug kernel by default (was: System size with -g) 
Message-ID:  <199904070645.OAA09741@spinner.netplex.com.au>
In-Reply-To: Your message of "Wed, 07 Apr 1999 15:38:21 %2B0930." <19990407153821.L2142@lemis.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote:
> On Wednesday,  7 April 1999 at 13:57:56 +0800, Peter Wemm wrote:
> > Greg Lehey wrote:
> > [..]
> >> A number of other people have observed that the current boot loader
> >> doesn't load the symbols anyway, so you could install /kernel.debug
> >> only and still run normally.  I consider this a deficiency in the boot
> >> loader, since it should be possible to load the symbols.  Of course,
> >> an alternative solution would be to install /kernel.debug and leave it
> >> until boot time to decide whether to load the symbols.  That would
> >> have the great advantage that you wouldn't get any mismatch between
> >> the two kernels.
> >
> > I'll chime in here since this was the result of something I spent a lot
> > of time on.
> >
> > A couple of points:
> > 1: The loader *does* load symbols, just not the debugging ones on elf. It
> >    does this for runtime linking purposes.
> 
> Good point.  I suppose that for the benefit of others I should point
> out that current kernels always (should) contain some symbols (see the
> reference to ps(1) in another message I sent.  We're talking about
> full ("debug") symbols here.

Yep, I've decided to take a shot at exporting the symbol table and lookup
to userland via dynamic sysctl's and see what I can do.  Then we can toast
kvm_mkdb and have libkvm look it up directly and also see kld's for free.

> > 2: Under ELF, the debug symbols are *seperate* to the symbol table.
> 
> Aren't they under a.out as well?  Otherwise strip(1) would have a lot
> of trouble stripping.  That's probably why the bootstrap doesn't load
> them, too.

No, under a.out they are all lumped together with different stab types.
The a.out strip process sifts through the list and keeps the ones it
wants.

Under ELF though, they are in different sections.  There's .dynsym which
has the symbols for the loader to use and they are in a PT_LOAD chunk and
get loaded along with the code.  Then there's the .symtab which contains a
verbose ELF symbol table that also includes static symbols (.dynsym
contains globals only).  The debug symbols are in their own sections,
usually .lineno*, .dwarf_* while .stabs_* has a.out-style symbols (*not*
ELF style symbols!).  .symtab and the others are generally not in the
PT_LOAD program segments, and locating them requires jumping all around
the file while getting the two PT_LOAD chunks is relatively easy.

> > On the whole though, I feel that the best way to deal with loading
> > extra debugging symbols is to do it shortly after boot.
> 
> Before or after starting process 0?

After, since they are not used for anything at all and just waste
unpageable kernel memory.

> > And on the subject of debugging kernels getting built, I'd tend to
> > agree.  Don't install them though, install the stripped version.
> 
> I had planned to leave that to the user: 'make install' will install a
> stripped kernel, 'make install.debug' will install the full symbol
> kernel.  I still think this is a reasonable compromise.

Yep.  I'd suggest modifying the Makefile to produce kernel.debug as the
final link stage, and then do a:

objcopy --strip-debug kernel.debug kernel

This will save a copy of a large file. :-)

> > Incidently, the loader works on kernels that have been plain
> > stripped too, but it's restricted to global symbols only as a
> > result.
> 
> I'm not sure I understand this.  By "plain stripped" do you mean strip
> -g or strip -s?  The way I see it, the result of 'strip -g' is
> identical to a kernel built without the -g option to config.

'strip /kernel' will work, and the loader still functions.  Once libkvm
looks up the runtime symbols, then ps etc will still work even on that
stripped kernel, or if the booted kernel is unavailable (ie: dosboot,
netboot from a tftp server etc).

> Greg

Cheers,
-Peter



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904070645.OAA09741>