renkel@motcid.UUCP (Will Renkel) (02/02/91)
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? Will Renkel - Motorola - Cellular 1501 W. Shure Drive - Room N258, Arlington Heights, IL 60004 (708) 632-4416 - ...uunet!mcdchg!motcid!renkel
dave@das13.snide.com (Dave Snyder) (02/03/91)
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. DAS -- David A. Snyder @ Snide Inc. - Folcroft, PA UUCP: ..!uunet!das13!dave INTERNET: dave@das13.snide.com
dnichols@ceilidh.beartrack.com (DoN Nichols) (02/03/91)
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 ---
jbm@uncle.uucp (John B. Milton) (02/07/91)
In article <1991Feb3.050750.13128@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: >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? The biggest is that most of the programs are nicely packed on the disk from when you did the installation. When you strip everything, it will scatter them all over the disk. Actually, sort of. On an idle machine it will tend to thrash them around in the same area of the disk due to the fact that UNIX puts most recently freeed block at the beginning of the free list. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:785-1110; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!