Reading the symbol table of the currently running executable

[Conor P. Cahill]

In article <679 at lakart.UUCP>, dg at lakart.UUCP (David Goodenough) writes:
> bcn at cs.washington.edu (Clifford Neuman) asks:
> >  [question about how to examine the symbol table at run time]
> 
> This is fairly grotesque, but it might just work:
> 
>    [ sample of using vfork/gcore deleted]
> 
> It does assume you have gcore, which living in /usr/ucb may be a beserkley
> enhancement. Still, it is possible to achieve the equivalent by opening
> /dev/mem (you can set this to run effective uid 0 right :-) ), seeking
> and reading, it's just a bit of an art to know where to go, and how much
> to grab.

Using gcore to generate a core image, or trying to read /dev/kmem won't
work because the executable image of a program at run time does not 
include the symbol table.  Why would the system choose to load a large
totally useless (as far as execution is concerned) portion of the executable
file?  There is no reason and it does not occur (Disclaimer: on any system
that I have seen, I guess there could be some exception).

Did you ever happen to note that you need an unstripped version of 
the program to examine a core file?  That is because the core file
does not have the symbol table, it is in the unstripped executable.

The only time that information is available is in the disk copies
of the programs executables, so if you need that information, you 
need to have read access to the executable.
-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+