geoff@utstat.uucp (Geoff Collyer) (09/17/90)
I note with displeasure that SGI ships binaries stripped of symbol tables, presumably to save scarce and expensive bytes on disk (:-), and not merely to make miserable the lives of users who lack source. Given the ever-dropping prices of disks and the utility of symbol tables (e.g. for giving stack traces of misbehaving programs to the hotline, or for patching global variables), is there any reason for SGI to continue shipping stripped binaries? I realise that COFF symbol tables can get large, but even minimal symbol tables (i.e. not enough for source-language debugging) would help. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
olson@anchor.esd.sgi.com (Dave Olson) (09/17/90)
In <1990Sep17.075217.18381@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: | I note with displeasure that SGI ships binaries stripped of symbol | tables, presumably to save scarce and expensive bytes on disk (:-), and | not merely to make miserable the lives of users who lack source. | Given the ever-dropping prices of disks and the utility of symbol tables | (e.g. for giving stack traces of misbehaving programs to the hotline, | or for patching global variables), is there any reason for SGI to | continue shipping stripped binaries? I realise that COFF symbol tables | can get large, but even minimal symbol tables (i.e. not enough for | source-language debugging) would help. There are many reasons for shipping stripped binaries, depending on who you talk to (few of the companies I have worked for have ever shipped unstripped binaries), but certainly disk spaces is a large one. MIPS compilers generate LARGE symbol tables. In a not atypical case, here are the sizes of /bin/csh on my machine, stripped, and unstripped: -rwxr-xr-x 1 olson engr 367280 Aug 9 10:10 csh -rwxr-xr-x 1 olson engr 221184 Sep 17 07:43 csh Note that 40% of the file is removed by stripping it... While it is true that most of customers are now buying larger disk drives, telling them to add another 100 Mb or so, just so binaries could be patched wouldn't go over to well! After all, we like to think we don't ship TOO many buggy programs :). -- Dave Olson Life would be so much easier if we could just look at the source code.
bean@putter.wpd.sgi.com (Bean Anderson) (09/18/90)
In article <1990Sep17.075217.18381@utstat.uucp>, geoff@utstat.uucp (Geoff Collyer) writes: |> I note with displeasure that SGI ships binaries stripped of symbol |> tables, presumably to save scarce and expensive bytes on disk (:-), and |> not merely to make miserable the lives of users who lack source. |> Given the ever-dropping prices of disks and the utility of symbol tables |> (e.g. for giving stack traces of misbehaving programs to the hotline, |> or for patching global variables), is there any reason for SGI to |> continue shipping stripped binaries? I realise that COFF symbol tables |> can get large, but even minimal symbol tables (i.e. not enough for |> source-language debugging) would help. |> -- |> Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu 1. The minimal SGI system has a 170MB drive (there's a ton of them in the field) and so our minimal software system must fit on that drive. Unstripped binaries would not fit. In addition, we generally don't want to force users to buy disk space for stuff that they may not use. 2. Tape space is, perhaps, even more important. Unstripped binaries would double the number of tapes required for a release. At our current size, that would add approximately $300,000 of cost per extra tape to our distribution cost. Our cost for the next release then will be approximately $1,000,000 extra just to have unstripped binaries. Those are two key reasons for stipping binaries. New distribution media (such as CD-ROM) will/may solve the second issue and maybe even the first as we could ship both stripped and unstripped binaries. Lastly, I totaly agree that some minimal symbol table information should be available. We are looking at that issue now. Bean
karron@MCIRPS2.MED.NYU.EDU (09/18/90)
Just to confuse the symbol table issue more, I note that most unix vendors leave the symbol table in /unix, and use it to debug a crashed kernel panic. If there is no symbol table in the progs that cause a kernel crash, then how can you be certain as to the programs that precipitated a crash. There is a gl library with the symbol table left in (a compile time option i noticed on the tapes). A symbol table should be left in for commands that probably might perhaps irritate the kernel and cause software failure. In the install process, you can pipe the binaries through strip and remove the symbol tables if you want, and restore binaries with the tables in if you want (or have the disk space). +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+
reuel@khaki.asd.sgi.com (Reuel Nash) (09/18/90)
In article <9009181645.AA18649@mcirps2.med.nyu.edu>, karron@MCIRPS2.MED.NYU.EDU writes: > Just to confuse the symbol table issue more, I note that most unix vendors > leave the symbol table in /unix, and use it to debug a crashed kernel panic. > I think a more important purpose for having the symbol table left in /unix is so programs like ps, who, and sar can know the addresses of various kernel data structures so they can be read or modified through /dev/kmem. SGI's kernel provides a call (sysmp) that gives these addresses, but some programs and most other vendor's systems still depend on the namelist in /unix. Reuel Nash Email: reuel@sgi.sgi.com "Rendering? You mean like hogs?" Voicemail: (415)962-3254 Mail stop:SR-254 Work Phone:(713)266-1333 Home Phone:(713)589-6258 USMail: Silicon Graphics, 5858 Westheimer Suite 100, Houston, TX 77057
ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz) (09/19/90)
In article <9009181645.AA18649@mcirps2.med.nyu.edu>, karron@MCIRPS2.MED.NYU.EDU writes: > Just to confuse the symbol table issue more, I note that most unix vendors > leave the symbol table in /unix, and use it to debug a crashed kernel panic. > > If there is no symbol table in the progs that cause a kernel crash, then > how can you be certain as to the programs that precipitated a crash. > > There is a gl library with the symbol table left in (a compile time option > i noticed on the tapes). A symbol table should be left in for commands that > probably might perhaps irritate the kernel and cause software failure. > > In the install process, you can pipe the binaries through strip and remove > the symbol tables if you want, and restore binaries with the tables in if > you want (or have the disk space). If the kernel is shipped with symbols for debugging purposes, a kernel debugger probably has access to the process tables which have information about which binaries (an a.out and some set of shared libraries) are associated with a process. User level binaries do not need to have symbol tables to do kernel debugging. There is usually enough information in this situation to determine the system call and arguments which a user level program invoked which caused the panic if that were truly the cause which is extremely rare. A common the cause of kernel panics is not due to any specific user level action but more likely some sequence of actions which cause mismanagement of internal kernel data structures. Having symbol tables in the all of the a.outs would not be of much help. In general, a symbol table is not required to determine the name of the a.out (binary) for a process which dumps core. The kernel keeps track of the a.out from which process text is loaded. When a process encounters an exception which causes the kernel to dump a core image of the process, the a.out name information is recorded. This a.out information may be inspected a number of ways: - In WorkSpace, open or double-click on a corefile icon - From the shell command line, type "file core" to get the info - For old hacks, type "strings core | more" A file's name shouldn't rely on the symbol table. Otherwise, changing a file name using "mv" would require changing the symbol table entry too. --- Ciemo