|
HP OpenVMS Systemsask the wizard |
|
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.)
|