From owner-freebsd-hackers Tue Apr 6 23:49: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id 8FB30156CE; Tue, 6 Apr 1999 23:48:46 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.3/8.9.3/Netplex) with ESMTP id OAA09741; Wed, 7 Apr 1999 14:45:25 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199904070645.OAA09741@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Greg Lehey Cc: Archie Cobbs , Christopher Michaels , gjb@comkey.com.au, questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Debug kernel by default (was: System size with -g) In-reply-to: Your message of "Wed, 07 Apr 1999 15:38:21 +0930." <19990407153821.L2142@lemis.com> Date: Wed, 07 Apr 1999 14:45:24 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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