Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!sgihub!dragon!bananaPC.wpd.sgi.com!ciemo
From: ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz)
Newsgroups: comp.sys.sgi
Subject: Re: lack of symbol tables in sgi distributions
Message-ID: <1990Sep18.175258.16047@relay.wpd.sgi.com>
Date: 18 Sep 90 17:52:58 GMT
References: <9009181645.AA18649@mcirps2.med.nyu.edu>
Sender: news@relay.wpd.sgi.com ( CNews Account )
Reply-To: ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz)
Organization: Silicon Graphics, Inc.
Lines: 43

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