From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 22:14:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51E6916A4CE; Wed, 20 Oct 2004 22:14:33 +0000 (GMT) Received: from web.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C869543D2F; Wed, 20 Oct 2004 22:14:31 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.100] (xDSL-2-2.united.net.ua [193.111.9.226]) (authenticated bits=0) by web.portaone.com (8.12.11/8.12.11) with ESMTP id i9KMELgW007000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2004 00:14:24 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4176E329.9090500@portaone.com> Date: Thu, 21 Oct 2004 01:14:01 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> In-Reply-To: <4176C0C8.4060408@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-current@FreeBSD.ORG cc: Ruslan Ermilov cc: freebsd-arch@FreeBSD.ORG Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 22:14:33 -0000 Scott Long wrote: > Ruslan Ermilov wrote: > >> On Wed, Oct 20, 2004 at 07:13:35PM +0200, Max Laier wrote: >> >>> Why is this discussion ongoing? The consensus seems pretty clear: >>> "Implement it, but have a make.conf option to turn it off." If there >>> is concern with this make if default to off and have an option to >>> turn it on. >>> >> >> Implementing this is very easy, since it's already implemented, >> just not by default. >> >> What everyone seem to have forgotten is that we also have modules, >> and in the "config -g" case, we also build debug versions of the >> modules. And if we're also going to install modules with debug >> symbols, I think this puts the requirement for the root file >> system way beyond the rational limits. >> >> >> Cheers, > > > I tend to agree. What do you think of my proposal to have installkernel > (optionally or whatever) put unstriped binaries somewhere outside of the > root partition? OK, I've just checked objcopy manpage and found that there is actually a better way which combines best properties of both approach. In modern GNU toolchain it is possible to split executable and debugging info into two separate files, but put a reference into executable, so that you don't have to worry about how to load debugging symbols: --only-keep-debug Strip a file, removing any sections that would be stripped by --strip-debug and leaving the debugging sections. The intention is that this option will be used in conjunction with --add-gnu-debuglink to create a two part executable. One a stripped binary which will occupy less space in RAM and in a dis- tribution and the second a debugging information file which is only needed if debugging abilities are required. The suggested proce- dure to create these files is as follows: 1. "foo" then... 1. create a file containing the debugging info. 1. stripped executable. 1. to add a link to the debugging info into the stripped exe- cutable. I checked, this works like a charm with our current toolchain/gdb. This allows us to do the following clever trick WRT kernel debug: 1. Compile kernel/modules with debugging symbols; 2. Split out executable and debugging pieces for each module; 3. Associate each executable file with appropriate debug file; 4. Install executable into /boot/kernel as usually; 5. Install real debugging into /var/something, put symlink to it into /boot/kernel. By the way, this approach can be extended to be an option of buildworld as well! It can be good way to trade developers' time for some hdd space, since with this option "on" you will always be able to debug misbehaving application/library without the need to recompile/reinstall everything! Opinions? -Maxim