home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / aix / 8813 < prev    next >
Encoding:
Text File  |  1992-08-14  |  2.1 KB  |  44 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!flu!marc
  3. From: marc@watson.ibm.com (Marc Auslander)
  4. Subject: Re: Detecting where program text segments come from...
  5. Sender: news@watson.ibm.com (NNTP News Poster)
  6. Message-ID: <MARC.92Aug14093051@marc.watson.ibm.com>
  7. In-Reply-To: fritz@scipp.UCSC.EDU's message of 13 Aug 92 19:17:21 GMT
  8. Date: Fri, 14 Aug 1992 14:30:51 GMT
  9. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  10. References: <16ecg1INN66f@darkstar.UCSC.EDU>
  11. Nntp-Posting-Host: marc.watson.ibm.com
  12. Organization: IBM T.J. Watson Research Center, Hawthorne, New York
  13. Lines: 29
  14.  
  15. The ublock contains the anchor of a chain of loader entries, one for
  16. each file used by the process as program text.  One is for the exec'd
  17. program, others for the shared or private modules (like libc) also
  18. loaded.  Each loader entry contains a pointer to the file table entry
  19. for the file it represents.  (The file table is the global kernel data
  20. structure which is used to represent open files.  The file descriptor
  21. entry in the u-block also points to a file table entry, for example).
  22.  
  23. The file table entry points to the Vnode for the open file.  From the
  24. Vnode it is possible to determine which mounted file system the file
  25. is in.
  26.  
  27. As is usual in unix, there is no easy way to determine a "path name"
  28. for the file from this information.  Some computation similar to that
  29. in getcwd() would be needed.  For all but the exec'd program,
  30. the path name used by the loader is recorded in the loader entry.
  31. The full path name of the exec'd program is not recorded in its loader
  32. entry.  (There's no good reason, but the internal interfaces didn't
  33. provide the path name to the loader, and when the recording of path
  34. names was added it was too late to fix it.  Oh well!)  (Of course,
  35. that path name may no longer name the same file.  In fact, the file
  36. may have no name at all, and be waiting for the process to end so it
  37. can be deleted from the file system.)
  38.  
  39. --
  40.  
  41.  
  42. Marc Auslander       (IBM)<marc@marc.watson.ibm.com>      914 784-6699
  43.                      (Internet)<marc@watson.ibm.com>
  44.