home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / misc / 801 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.0 KB
  1. Xref: sparky vmsnet.misc:801 vmsnet.internals:1294
  2. Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!sdd.hp.com!hamblin.math.byu.edu!yvax.byu.edu!heinrich
  3. From: heinrich@yvax.byu.edu (Ed Heinrich  - The LOKI Group, Inc.)
  4. Newsgroups: vmsnet.misc,vmsnet.internals
  5. Subject: Re: Analyzing a process dump
  6. Message-ID: <1992Sep7.121532.914@yvax.byu.edu>
  7. Date: 7 Sep 92 19:15:32 GMT
  8. References: <lac6ibINN7h8@news.bbn.com>
  9. Distribution: na
  10. Organization: Brigham Young University
  11. Lines: 52
  12.  
  13. In article <lac6ibINN7h8@news.bbn.com>, mjensen@BBN.COM (Martin Jensen) writes:
  14. > Greetings again vms.wizards ...
  15. > 
  16. >     One more question, then I promise I'll leave you alone ... for a
  17. >     while anyway :-)
  18. > 
  19. >     I've got an executable that runs with the /dump qualifier.  I expect
  20. >     that, on occasion, the process will crash.  (as a matter of fact, we
  21. >     intentionally crash it if software detects an unrecoverable condition
  22. >     in the code).
  23. > 
  24. >     The problem is that the dump files are pretty useless.  'show  calls'
  25. >     reports  only the module names - no routine names - and I've only got
  26. >     access to universal symbols.  The program is compiled with the /debug
  27. >     switch and linked with /trace.
  28. > 
  29. >     If  I  link  with  /debug,  I get the debugger linked in.  I've tried
  30. >     linking with /debug=foo (where foo contains  the  program  main)  ...
  31. >     that  seems  to  work  (outside  of  some strange symbol behavior for
  32. >     objects in foo), but now I've got the overhead  of  the  DST  in  the
  33. >     runtime image.
  34. > 
  35. >     Ideally, I would like to be able use anal/proc/image=xxx against the
  36. >     dump from the normally linked executable - where xxx would be an
  37. >     image containing the full DST and GST.  The couple of options I have
  38. >     tried allow me to analyze the dump, but the symbol locations don't
  39. >     match properly between the images.
  40. > 
  41. >     Any ideas???
  42. > 
  43. > 
  44. > ---   Martin Jensen     \   BBN Communications     \  #include          ---
  45. >  ---   mjensen@bbn.com   \   150 CambridgePark Dr.  \  <std.disclaimer>  ---
  46. >   ---   (617) 873-4859    \   Cambridge, MA   02140  \                    ---
  47.  
  48.  
  49.  
  50. ANA/PROCESS has a /IMAGE qualifer.  One option you have, assuming you want
  51. to keep two copies, which is sometime advantageous, is when building the 
  52. image perform two links:  One with DEBUG and one w/out.  The non-debug
  53. version can always be executed as the production version.  The /DEBUG
  54. version is specified as the image to use for obtaining the symbols when
  55. examining the dump via the /IMAGE= qualifier.  (Obviously you will want to
  56. name the DEBUG image w/ a different file name or extension). This does, of 
  57. course, eat up more disk space but leaves you with a version that can be used 
  58. for debugging w/out having to rebuild from - possibly modified - sources.
  59.  
  60. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  61. Ed Heinrich
  62. The LOKI Group, Inc.
  63. HEINRICH@yvax.byu.EDU
  64. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  65.