Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!uunet!beartrk!ceilidh!dnichols
From: dnichols@ceilidh.beartrack.com (DoN Nichols)
Newsgroups: comp.sys.3b1
Subject: Re: UNIX size
Keywords: size, strip
Message-ID: <1991Feb3.050750.13128@ceilidh.beartrack.com>
Date: 3 Feb 91 05:07:50 GMT
References: <4623@apricot17.UUCP> <1478@das13.snide.com>
Organization: D and D Data, Vienna, VA.
Lines: 59

In article <1478@das13.snide.com> dave@das13.snide.com (Dave Snyder) writes:
>In article <4623@apricot17.UUCP>, renkel@motcid.UUCP (Will Renkel) writes:
>> I noticed most pgms in UNIX are NOT stripped of the symbol table.
>> Does anyone know about how much space these un-necessary symbol tables take up
>> Can they be stripped without any problems?
>> 
>I've stripped every executable on my machine EXCEPT /unix.  I've noticed no
>problems as of yet.

	The main thing that you loose is the ability to use a debugger with
a core dump of a failed program to determine where it crashed.  Usually,
this is of importance when you posess the source code to attempt repairs,
but might also be useful to your support from the manufacturer/vendor :-)

	Sometimes, however, this kind of examination can lead to a clue as
to how you crashed the program with strange input data.

	Since we currently have little expectation of support on this
machine, perhaps stripping all the binaries is harmless, except for /unix.
Other programs depend on it having a symbol table, so they can know where in
/dev/kmem to look for specific entries.  Programs such as 'ps' are very
dependant on this.  (They could be made to know the proper offsets for each
needed entity in the kernel, but then these programs would have to be
re-compiled and sent out with every new kernel.)

	If you have a taste for adventure, you might FIRST MAKE A COPY of
the kernel, then strip the working kernel, and keep a list of how many
programs break.  (You could also do this by making /unix and /dev/kmem
unreadable by anyone, and turning off the suid bit on any suid-root programs
in the system.  On one of my systems, an old v7 UNIX on the mc68000, this
would even break kermit, since it has to grovel around in the kernel to
determine the number of characters in the input queue.  (The appropriate
ioctl is present to perform this function, but is documented in the header
files to not work on the particular serial port hardware in use on this
system.

	My personal practice is to keep new programs (Those which I have
developed, and those from the wealth of source sources on the net)
unstripped, at least till I have some real confidence in them.  Typically, I
will strip them at about the time that I move their source tree to archive
media.

	If space is really tight, an alternative is to keep an unstripped
copy of the code on backup media, while running a stripped copy.  As long as
the stripped copy was made from the unstripped one, the information
contained in the unstripped copy's symbol table is valid for the stripped
copy as well, and the unstripped copy can be restored and used for the
debugger.  (Be careful that the stripped and unstripped copies are truly
from the same origin.  Even a later compiler run from the same source code
may be enough different to cause problems.  (Certainly the date stored in
the COFF header will be different, and the librarys may have been changed.

	Strip with caution, and enjoy
		DoN.
-- 
Donald Nichols (DoN.)		| Voice (Days):	(703) 664-1585
D&D Data			| Voice (Eves):	(703) 938-4564
Disclaimer: from here - None	| Email:     <dnichols@ceilidh.beartrack.com>
	--- Black Holes are where God is dividing by zero ---