From owner-cvs-all Sat Jun 10 6:46:59 2000 Delivered-To: cvs-all@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id A2F3C37BA90 for ; Sat, 10 Jun 2000 06:46:46 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 19525 invoked from network); 10 Jun 2000 13:46:42 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 10 Jun 2000 13:46:42 -0000 Date: Sat, 10 Jun 2000 23:46:38 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Wemm Cc: Greg Lehey , Bruce Evans , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: Booting debug kernels (was: cvs commit: src/sys/i386/i386 locore.s) In-Reply-To: <20000610105742.7BCE31CE1@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jun 2000, Peter Wemm wrote: > Greg Lehey wrote: > > On Friday, 9 June 2000 at 19:54:19 +1000, Bruce Evans wrote: > > > On Fri, 9 Jun 2000, Greg Lehey wrote: > > > > > >> On Thursday, 8 June 2000 at 10:53:44 -0700, Bruce Evans wrote: > > >>> bde 2000/06/08 10:53:43 PDT > > >>> > > >>> Modified files: > > >>> sys/i386/i386 locore.s > > >>> Log: > > >>> Always include the full symbol table (as specified by its start and > > >>> end values in bootinfo) in kernel space if it is loaded (i.e., if its > > >>> specified end address is nonzero), not just if it is loaded and DDB > > >>> is configured. This may be used to fix kldsym(2) for booting without > > > > > >> I think this is worth a HEADS UP, or at least a mention in UPDATING. > > > > > > I disagree. This only affects broken configurations. > > > > This is an unsubstantiated claim. Even if you were to substantiate It only affects very broken configurations. First, the kernel must be inadequately stripped to match its intended use (more than symbols can probably be stripped if space is short). Second, the kernel must be booted without using /boot/loader get the symbols loaded by boot2 thrown away. I think /boot/loader was supposed to become non-optional, but I don't believe in it so I don't use it, and not using it is apparently good when space is short (on laptops and embedded systems), so not using it may become officially supported. > > it, it doesn't alter the fact that a lot of people have taken notice > > of the fact that you can now boot from a debug kernel and not suffer > > the bloat of the symbol table. If we change that, we should draw it > > to people's attention. > > That is irrelevant. ELF keeps it's debug info seperate from the symbol > table - *that* is why we can boot a debug kernel without any size side > effects. I verified this. Stripping is done using "objcopy --strip-debug" in the elf case. This strips the .stab and .stabstr sections and reduces the kernel size by about 7MB in my configuration. boot2 apparently doesn't load these sections. The "full symbol table" ends up having size 360628 bytes, which is about 10K larger than the reduction in the kernel size caused by a full strip on the kernel binary, so it is clear that not much space is been wasted for the symbol table (except internally -- there are a lot of useless symbolds in the 350K). > All that Bruce has changed is that when you bypass loader(8) and boot from > boot2 directly, any unstripped symbol table (NOT debug symbols) are > preserved so that vmstat(8) etc can see static symbols. I added about 350K unstripped symbol table. vmstat(8) etc. can't actually see it yet when loader(8) is bypassed. This should be fixed if bypassing loader(8) is supported. > > >> Is there any way to boot such a kernel and discard the symbols? > > > > > > Not at boot time. Use strip(1) to strip unwanted symbols. The symbol > > > table has become very bloated even for non-deubugging kernels, but > > > boot time is not the time to reduce it. > > > > I think what you're trying to say here is "it's too difficult to do at > > boot time", but it's difficult to tell. Maybe you're trying to say "I It breaks the tools philosophy, and _is_ too difficult to program all the stripping possibilities in strip(1) and objcopy(1) into the boot code. >>... > I think you are misunderstanding. This only affects booting directly via > boot2 and not the normal way using loader(8). > > loader sets bootinfo.bi_kernend, which overrides the bump of the end > of kernel space, so the section of code bde changed is unaffected here. > (boot2 does not set bi_kernend, so it's rather important in that case). > > Nothing (in the tree) except db_aout.c looks at bi_symtab,bi_esymtab at > present. This was important in the !DDB case, since bi_symtab and bi_esymtab were garbage. > Also note that a.out kernel builds are utterly impossible now > that we depend on the new binutils bugfixes, so db_aout.c is even more > irrelevant. I'm not sure about that. The syntax fixes are backwards compatible (they check things more strictly). Someone forgot to cvs-remove db_aout.c although they removed it from conf/files. I didn't remind them because I thought it might be useful to compare with until the elf and kld support is finished. I use an updated version of db_elf.c, which was cvs-removed, to work around some bugs in db_kld.c (it doesn't work early in the boot, and doesn't strip "gcc2_compiled." and maybe a couple of other unwanted symbols, and seems to have more sign extension problems on i386's with 64 bit longs). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message