From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 23:13:43 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 80BEC16A4CE; Wed, 20 Oct 2004 23:13:43 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5588143D1D; Wed, 20 Oct 2004 23:13:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i9KNDjrk024523; Wed, 20 Oct 2004 16:13:45 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i9KNDjKN024522; Wed, 20 Oct 2004 16:13:45 -0700 Date: Wed, 20 Oct 2004 16:13:45 -0700 From: Brooks Davis To: Maxim Sobolev Message-ID: <20041020231345.GA23289@odin.ac.hmc.edu> 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> <4176E329.9090500@portaone.com> <4176E71D.9090500@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <4176E71D.9090500@portaone.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Max Laier cc: freebsd-current@freebsd.org cc: Scott Long 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 23:13:43 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2004 at 01:30:53AM +0300, Maxim Sobolev wrote: > Maxim Sobolev wrote: >=20 > >OK, I've just checked objcopy manpage and found that there is actually a= =20 > >better way which combines best properties of both approach. In modern=20 > >GNU toolchain it is possible to split executable and debugging info into= =20 > >two separate files, but put a reference into executable, so that you=20 > >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= =20 > >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=20 > >/boot/kernel. > > > >By the way, this approach can be extended to be an option of buildworld= =20 > >as well! It can be good way to trade developers' time for some hdd=20 > >space, since with this option "on" you will always be able to debug=20 > >misbehaving application/library without the need to recompile/reinstall= =20 > >everything! >=20 > BTW, it also allows us to do create separate "debug" distribution for=20 > release CDs. So that one can do binary install and then add debugging=20 > symbols if necessary. I like this idea. A nice feature of this is that you could stick the debug distribution somewhere other then on disk1 so that space could be saved for packages. I'm not sure that would be a good idea, but it would give us more trade space then the current all or nothing setup. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBdvEoXY6L6fI4GtQRAnh6AJ0ViQhwQNEZHZovafRigJTg5srkfwCfemTI d1/xVAJiD2xjdAntBNLOViM= =F77C -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V--