HP OpenVMS Systems

Help debugging an ACCVIO? /OPT vs /NOOPT?

» close window

The Question is:

 
Some of the OpenVMS Alpha code I'm working on in DECC will die with an access
violation in the optimized version only.  I've compiled and linked the code /
debug/optimize but for many of the variables I try to examine, I get this
debugger error message:
 
%DEBUG-W-NOTVALATPC, entity 'my_variable' does not have a value at the
current PC (was optimized away)
 
I'm guessing these variables are really stored on the stack, and I've been
stepping through the assembly code trying to find out where they are really
located in memory so I can put a watch on those areas and find out how they
might be getting corrupted.
 
 
Can you direct me to any documentation about how the calling procedure works
in DECC-generated Alpha code so I can make better sense out of this assembly
code -- or better yet, is there a simple way I can locate the address in
memory of variables which are "optimized away"?
 
 

The Answer is :

 
  Most (all?) compilers make heavy use of the stack for storage of
  temporary variables.  There is no released documentation that I
  am aware of that covers how the GEM compiler back-end performs its
  variable allocation and optimization processing.
 
  For information on the calling standard and the associated modular
  programming guidelines, please see the OpenVMS documentation set.
 
  Start with DEC C V5.7 or later, for better diagnostics.
 
  The access violation has a number of pieces of information that
  can often be used to piece together what was happening when the
  access violation occured -- in an optimized image, this may mean
  the use of compiler listings and the linker map to locate the
  particular PC that tried to access the (prohibited) virtual address.
  The reason mask indicates if the operation was a read or a write,
  or one of a few other sorts of operations.  For information on the
  particular meaning of ACCVIO arguments, use HELP/MESSAGE ACCVIO.
 
  As for debugging this, look for buffer overruns and cases where the
  null byte was not accounted for, look for improperly synchronized
  asynchronous completions, storage that is volatile over the life of
  the asynchronous call, incorrect or omitted return and IOSB status
  checks, incorrect sharing of IOSBs or event flags, failure to check
  both for a non-zero IOSB and the event flag on completion, dynamic
  storage overruns, failure to centralize critical operations such
  as dynamic memory management, a lack of integrated application
  debugging support, etc.
 
  Also take a look at the heap analyzer in the debugger.  (This is
  a recent (V7.x) feature on OpenVMS Alpha, but has been available
  for a while on OpenVMS VAX.)
 

  

     

     
answer written or last revised on ( 15-JUL-1998 )
     
» close window