How can a program find path to its binary file?

Greg Hunt hunt at dg-rtp.rtp.dg.com
Tue Apr 30 02:49:31 AEST 1991


In article <1991Apr29.120203.13498 at lth.se>, kenny at dit.lth.se (Kenny Ranerup) writes:
> I've written a signal handler that writes out a stackdump if a program
> gets e.g. a SEGV signal. However, I want to write out the stackdump
> with symbolic procedure names if symbolic information is available in
> the binary file. The question is, how can my signal handler find the
> path to the binary file so that it can read in the symbol table?

Unfortunately, there is no foolproof way of doing it.  You can try
these things, though, and you'll find they'll work most of the time:

o  Look at the argv[0] passed into the program.  In most cases, it
   will be the simple name of the binary.  There is no guarantee that
   it will be, since it is not a requirement of the exec family of
   calls that they pass the binary name as argv[0].  Also, the process
   itself can change argv[0], so it might have been overwritten.  This
   can be done to change what ps, for example, reports as the command
   that the process is executing.

   If argv[0] is an absolute pathname (beginning with /) or a relative
   pathname (beginning with ./ or ../), then you can use that pathname
   and hope that it really refers to the binary.  Be careful of relative
   pathnames if the process has changed it's working directory, they'll
   be relative to the process's initial working directory, not its
   current one.

o  If argv[0] is not an absolute or relative pathname, then get the
   value of the $PATH environment variable (see getenv), and search for
   the file using the directories on the path.  Take each directory
   name in order and concatenate the argv[0] value to it and then
   see if the target file exists (see access).  If you find a match,
   then hope that its the binary file.  Since this is the way the
   shells start programs, it's got a fair chance of working as well.

Good luck!

-- 
Greg Hunt                        Internet: hunt at dg-rtp.rtp.dg.com
DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC, USA  These opinions are mine, not DG's.



More information about the Comp.unix.questions mailing list