[Fwd: What do people think about not installing a stripped /kernel ?]

[Brooks Davis]

On Thu, Oct 21, 2004 at 01:30:53AM +0300, Maxim Sobolev wrote:
> Maxim Sobolev wrote:
> 
> >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.<Link the executable as normal.  Assuming that is is called>
> >   "foo" then...
> >
> >   1.<Run "objcopy --only-keep-debug foo foo.dbg" to>
> >   create a file containing the debugging info.
> >
> >   1.<Run "objcopy --strip-debug foo" to create a>
> >   stripped executable.
> >
> >   1.<Run "objcopy --add-gnu-debuglink=foo.dbg foo">
> >   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!
> 
> BTW, it also allows us to do create separate "debug" distribution for 
> release CDs. So that one can do binary install and then add  debugging 
> 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

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041020/0e961731/attachment.bin