From owner-kdb@oss.sgi.com Tue Nov 2 09:40:15 1999 Received: by oss.sgi.com id ; Tue, 2 Nov 1999 09:40:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:60778 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Nov 1999 09:39:48 -0800 Received: from griffin.engr.sgi.com (griffin.engr.sgi.com [150.166.42.40]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA01802 for ; Tue, 2 Nov 1999 09:45:16 -0800 (PST) mail_from (slurn@griffin.engr.sgi.com) Received: (from slurn@localhost) by griffin.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id JAA36787; Tue, 2 Nov 1999 09:42:18 -0800 (PST) From: slurn@griffin.engr.sgi.com (Scott Lurndal) Message-Id: <199911021742.JAA36787@griffin.engr.sgi.com> Subject: Re: [PATCH] KDB for 2.3.23 In-Reply-To: <99Nov2.033353edt.121764@gpu.utcc.utoronto.ca> from Chris Siebenmann at "Nov 2, 99 03:33:52 am" To: cks@utcc.utoronto.ca (Chris Siebenmann) Date: Tue, 2 Nov 1999 09:42:14 -0800 (PST) Cc: kdb@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing > You write: > | Meanwhile, I've been working on v0.6 of kdb for 2.2.13 and > | am reorganizing kdb sources to split into machine dependent and > | machine independent parts, with rudimentary mips and itanium support, which > | will become version v1.0 of kdb and will be relative to the > | 2.3 series kernels. > > I'd like to urge a change in how kdb-enabled kernels currently build. > In the kdb-v0.5-2.2.10 patch, you always reserve a fixed amount of > space in kern/arch/i386/vmlinux.lds for kdb symbols. As I understand > it, this is so you can easily get the addresses of the kernel symbols: > link the kernel once, pull the symbols out, and relink -- you know > that because the space reserved for the symbol table is fixed, the > symbols won't change address between builds. > > Unfortunately, I believe that this approach has two deleterious > consequences: > - if you have too many symbols, or too long symbols (such as if you > turn on CONFIG_MODVERSIONS) you can overflow the assigned space; > the resulting kernel builds without error but will probably crash > instantly on boot. With the v0.6, which I've been using internally, the max number of symbols is a configurable option, and the default is much larger (9000). With the AC12 patches to 2.2.10, the vmlinux.lds file is now run through cpp so the space reservation can be conditioned on CONFIG_KDB and the amount reserved can be based upon CONFIG_KDB_STBSIZE, which is better than v0.5. For v1.0 (which will be against the 2.3 kernel series), I'll look at finding a better way. I've several suggestions from various folks to look at. > - because the space reservation is independant of whether CONFIG_KDB > is turned on, adding the kdb patch to your kernel is not a cost-free > thing if you never turn it on; you always eat up 192K or so of kernel > space. This makes it unsuitable for adding the patch to general > kernel distributions (or keeping in a local kernel), which I think > is a pity. See above - vmlinux.lds is preprocessed which eliminates this issue. > > I'd like to suggest that you eliminate the fixed symbol table space and > move kdb-enabled kernels to a three-link approach, where the first link > lets you count how many symbols there are to accurately size the symbol > table space, the second link generates the correct data for the symbols, > and the third glues everything together correctly. (Hmm. I wonder if > there's some way to use the binutils ELF tools to just shove the symbol > data into the vmlinux file without actually bothering to relink, since > the only job of the third relink is to do basically that.) I'll keep this approach in mind for v1.0. thanks, scott > > --- > "I shall clasp my hands together and bow to the corners of the world." > Number Ten Ox, "Bridge of Birds" > cks@utcc.toronto.edu utgpu!cks >