Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

How to Watch in debugger a module variable in a DLL VS2013/PSXE2017

dajum
Novice
310 Views

We used to enter the module name + :: + variable name and that worked in older times.  I'm not sure if it is the code versions being used or the fact the modules are in a dll that is the issue.  But it makes debugging hard, and I could find any discription of how this works in the documentation. Can you point me to documentation that explains how to do this? And hopefully explain here what to do. We just get "undefined variable" alot.  We see this a lot in subroutines, where we can't view local variables with quickwatch or watch. THere seems to be lots of scoping issues and again it makes debugging difficult. 

Thanks

Dave

0 Kudos
3 Replies
dajum
Novice
310 Views

Also how to use such variables in a conditional breakpoint would be nice to know, as that doesn't seem to work either.

0 Kudos
jimdempseyatthecove
Honored Contributor III
310 Views

The debugger cannot locate a variable in a module within a DLL until after the DLL is loaded. What I typically do to aid debugging is to add an innocuous subroutine "FindMyDLL" that does nothing (and is not optimized out). I place a call to this in the beginning of the program, and then step into it. Once there, then the DLL is present and the address can be resolved.

If the :: cannot resolve the name, try

YourModuleName_MP_TheVariableName

For break on condition (e.g. write to location), get the address of variable by using Memory Watch, copy address to paste buffer, then:

Debug | Break Points | Add New | Add data break point | C/C++ | paste in address | number of bytes 4 or 8

I've had issue with entering the symbolic name in the data break location edit box.

Jim Dempsey

0 Kudos
dajum
Novice
310 Views

Thanks Jim,

Unfortunately this is durring program execution. So the DLL has been loaded and used.  I do this while at a breakpoint in the execution. In a routine where the module has been used, but the variable within the module isn't referenced.  Using YourModuleName_MP_TheVariableName or even the __imp_ version listed in the .map file.  The ties to the Microsoft products used to do all the debugging seems to be very weak.  Changes and breaks often with new versions, while most of this used to work.  Some support from Intel in this area to use the code would be appreciated. 

0 Kudos
Reply