Reading the symbol table of the currently running executable

[Clifford Neuman]

Thanks for all the responses to my question on reading the symbol
table from a running program.  As promised, here is a summary of
responses.

Approach one: Directly reading the symbol table from within the
running program.

  A number of people suggested including the symbol table as an integral
  part of the program.  This is best accomplished by declaring a large
  static and initialized data area within the program.  Once the program
  is linked the executable can then be postprocessed to copy the symbol
  table into data area.  This approach has the added advantage that even
  if someone later strips the executable, the copied symbol table
  remains.

  If it is known ahead of time which symbols will be needed, then you
  can compile your own symbol table into the program, and do away with
  the postprocessing entirely.  In my case, I am doing dynamic linking,
  but it was acceptable for me to restrict the procedures that should be
  callable.  This is the approach I am using.

Approach two: Obtaining the full path name of the presently running
executable.  Remember, argv[0] will not contain the full path if the
executable was found through the search path.  Also, the program may
have been started by execl with an argv[0] that is unrelated to the
file name.

  There were basically two ways of approaching the problem from this
  angle.  In the simplest approach, one would create a wrapper script
  which would call the desired program with the full path name, and the
  user would call the wrapper.  This assumed, of course, that user never
  called the actual program directly.  It also required that the wrapper
  know where the program is installed.

  In the second approach, one searched the path to find the executable
  with the name found in argv[0].  This approach makes a few
  assumptions, but in most situaltions, it would work.  The code to do
  the search was posted to this newsgroup.

  One response pointed out that ksh sets a variable  $_ that refers
  to the full path of the file to be executed, and suggested looking
  at it.  Another suggested looking at the "-c" option to ps.

Approach three: Obtaining a file descriptor for the currently running
executable (i.e. I don't need the name as long as I can read it).

  The answers along this lines involved adding a new device
  (/dev/text) with an open routine that creates a file descriptor
  pointing at the inode hidden in the text structure.

Again, thanks to everyone who responded.  Responses were received from
Bill Griswold (who also implemented, and made the necessary cahnges to
the dynamic linking package I am using), Bill Sommerfeld, Chris Torek,
Oliver Laumann, Rich Salz, Conor P. Cahill, David Barts, Adam R de
Boor, David Goodenough, Guy Harris, Gordon Burditt, Greg Limes, Mark
Rosenthal, Dan McCue, Perry Hutchison, siswat!buck at gazette.bcm.tmc.edu, 
and vsi!friedl at uunet.uu.net.

	~ Cliff