accessing values of variables during debugging

[forall]

A possibly rather ambitious question: Is it possible in some way (direct or indirect) to access the variables (values or addresses - doesnt matter) during the debugging and send them to my own analysis procedure?

My context is as follows: I am developing a fairly large numerical code for analysis of distributed systems that has many matrix and array variables. During debugging, I would like to be able to check their mathematical properties (eg, eigenvalues, determinant, etc). Similarly for many other variables I would like to be able to check some of their properties during debugging (satisfaction of some conditions, etc) using fairly complicated auxiliary algorithms.

I realize this could be achieved by embedding CALLs to these auxiliary procedures directly into the code, however this is rather cumbersome because I have 100's or more variables that I may be interested during debugging, and not always at the same time. Rebuilding the code everytime I want to examine some variable in more detail is also time-consumming, and so would be developing a system of flags to enable/disable calls to the auxiliary routines.

Moreover once the code is debugged I dont anticipate needing these checks, but expect to need the same debugging approach for future projects.

Given the existence of Watch windows, Array Visualizer, etc, I was wondering if a more flexible option is possible.

In particular, is it possible to apply a "tool" to a highlighted or otherwise "selected" variable in the debugger? Something analogous to array visualizer, where a highlighted variable (or typed into a separate window such as the Watch window) can be sent to a plotting routine. In my case I would just send to my own procedure (available as DLL, or coded via VB, or in any other form because I would have its source)

Some kind of possible option would be to have a Macro that automatically copies/pastes the contents of a variable into a data file to be read by my procedure, but this doesnt work very well for matrices (because rightclick > copy on a mtrix only copies its name, not its contents..)

any comments/advice would be appreciated

[Steven_L_Intel1]

I can't think of a way for you to hook into the debug information.

[Lorri_M_Intel]

Quoting - forall

A possibly rather ambitious question: Is it possible in some way (direct or indirect) to access the variables (values or addresses - doesnt matter) during the debugging and send them to my own analysis procedure?

My context is as follows: I am developing a fairly large numerical code for analysis of distributed systems that has many matrix and array variables. During debugging, I would like to be able to check their mathematical properties (eg, eigenvalues, determinant, etc). Similarly for many other variables I would like to be able to check some of their properties during debugging (satisfaction of some conditions, etc) using fairly complicated auxiliary algorithms.

I realize this could be achieved by embedding CALLs to these auxiliary procedures directly into the code, however this is rather cumbersome because I have 100's or more variables that I may be interested during debugging, and not always at the same time. Rebuilding the code everytime I want to examine some variable in more detail is also time-consumming, and so would be developing a system of flags to enable/disable calls to the auxiliary routines.

Moreover once the code is debugged I dont anticipate needing these checks, but expect to need the same debugging approach for future projects.

Given the existence of Watch windows, Array Visualizer, etc, I was wondering if a more flexible option is possible.

In particular, is it possible to apply a "tool" to a highlighted or otherwise "selected" variable in the debugger? Something analogous to array visualizer, where a highlighted variable (or typed into a separate window such as the Watch window) can be sent to a plotting routine. In my case I would just send to my own procedure (available as DLL, or coded via VB, or in any other form because I would have its source)

Some kind of possible option would be to have a Macro that automatically copies/pastes the contents of a variable into a data file to be read by my procedure, but this doesnt work very well for matrices (because rightclick > copy on a mtrix only copies its name, not its contents..)

any comments/advice would be appreciated

You say doing from the Watch window is OK? One can call a routine ACCESSIBLE THROUGH THE IMAGE BEING DEBUGGED from the watch window, and pass it avariable from the program.

One of my usual tricks is to set a break at an"interesting" function, and put a line in the Watch window thatcalls our internal dump routine associated with theentity being passed to the function. Yes, I have to click "Continue" until theproblematicentityappears in the function, but it is certainly do-able.

So, you could write your own dump/store/manipulative routine, link it in with your application, and set breaks wherever it seemed right. Oh, and you can conditionalize out the routine based on whether the application was built /debug or not, in case you were worried about code bloat or security with the final release product.

- Lorri

[forall]

Quoting - Lorri Menard (Intel)

You say doing from the Watch window is OK? One can call a routine ACCESSIBLE THROUGH THE IMAGE BEING DEBUGGED from the watch window, and pass it avariable from the program.

One of my usual tricks is to set a break at an"interesting" function, and put a line in the Watch window thatcalls our internal dump routine associated with theentity being passed to the function. Yes, I have to click "Continue" until theproblematicentityappears in the function, but it is certainly do-able.

So, you could write your own dump/store/manipulative routine, link it in with your application, and set breaks wherever it seemed right. Oh, and you can conditionalize out the routine based on whether the application was built /debug or not, in case you were worried about code bloat or security with the final release product.

- Lorri

Hi Lorri,

Thanks - this could well address my problem almost perfectly! Now I just need to get it to work in principle :-)

I tried to do this, setting up "debugging" functions isPD() and isPDmod() both inside a separate "debugging" module and as standalone. I also placed breakpoints inside them.

But I was unable to execute these functions from the debugger. In both cases I get a "Not Implemented" message (see attached screenshot of my test setup). If I click "continue" my main code just executes as normal, never entering isPD. I use Intel Fortran 11.0.072. Is this a new feature of a new release?

~dmitri

[Lorri_M_Intel]

Quoting - forall

Hi Lorri,

Thanks - this could well address my problem almost perfectly! Now I just need to get it to work in principle :-)

I tried to do this, setting up "debugging" functions isPD() and isPDmod() both inside a separate "debugging" module and as standalone. I also placed breakpoints inside them.

But I was unable to execute these functions from the debugger. In both cases I get a "Not Implemented" message (see attached screenshot of my test setup). If I click "continue" my main code just executes as normal, never entering isPD. I use Intel Fortran 11.0.072. Is this a new feature of a new release?

~dmitri

Alas, I have to retract my statement ... You are absolutely correct. This does not work. I've been muddling with this for a significant portion of the morning, and nothing I've done has made it work.

In my own defense ;-) we do this all the time with the compiler project itself, but that is strictly C/C++. I think theexistence of Fortran is what has caused the issue here.

I'm so sorry for dashing your hopes.

- Lorri

PS: Note to self; never disagree with Steve ...

[Steven_L_Intel1]

Disagreeing with Steve is often useful. I think in this case it is the Fortran Expression Evaluator that does not support this feature. (Lorri, you and I perhaps can pay a visit to Jeff A.)

[jimdempseyatthecove]

Assuming what you want to do can be expressed in advance, why not use the Array Visualizer? The Array Visualizer has an API (not just usable from a debug window). One of the capabilities is the avStartWatch to specify the array or location to watch and then (whenever desired) avUpdate to "freshen" the watched data.

For the eigenvalue case, you watch your 100's of variables but "plot" / examine the eigenvale for one of these variables. Then in the AV viewer window, left pane, in the tree view, find the plot, right click and properties the branch. One of the property pages contains the path to the variable of interest. For the variables being watched, you can either type in the variable (array)name or browse the data list and insert the pathname into the plot.

In your debug build, anything and everything that potentially is (or will be) of interest can be avStartWatch'd. Then one or a few well placed avUpdate calls is all that is necessary to get the data into AV for your manipulation. This is a little wierd to do at first but very useful once you discover this capability.

Jim Dempsey

[forall]

Quoting - Steve Lionel (Intel)

Disagreeing with Steve is often useful. I think in this case it is the Fortran Expression Evaluator that does not support this feature. (Lorri, you and I perhaps can pay a visit to Jeff A.)

I think if this facility could be implemented for the Fortran Evaluator it would constitute a very significant improvement. The fact that it already exists for C/C++ would suggest its implementation is feasible.

[forall]

Quoting - jimdempseyatthecove

Assuming what you want to do can be expressed in advance, why not use the Array Visualizer? The Array Visualizer has an API (not just usable from a debug window). One of the capabilities is the avStartWatch to specify the array or location to watch and then (whenever desired) avUpdate to "freshen" the watched data.

For the eigenvalue case, you watch your 100's of variables but "plot" / examine the eigenvale for one of these variables. Then in the AV viewer window, left pane, in the tree view, find the plot, right click and properties the branch. One of the property pages contains the path to the variable of interest. For the variables being watched, you can either type in the variable (array)name or browse the data list and insert the pathname into the plot.

In your debug build, anything and everything that potentially is (or will be) of interest can be avStartWatch'd. Then one or a few well placed avUpdate calls is all that is necessary to get the data into AV for your manipulation. This is a little wierd to do at first but very useful once you discover this capability.

Jim Dempsey

thanks Jim - I will try this. I assume you are referring to the intel AV?

[jimdempseyatthecove]

Yes, I refer to the Intel AV (free download).

When I simulate space elevators I often throw additional data into the avStartWatch database. Then the information is present. When the avUpdate is issued (periodically in my application) the data becomes visible within AV. Because AV runs as a seperate process, I can view, plot, write new plots, etc... while the simulation program is running.

In the case of your eigenvalues, you might be able to construct a visualization plot of multiple data points. A representation that visually exposes an exception or convergence. By viewing this plot (or others) you can track the convergence or divergence of the test case. Often is the case that you will be unable to specify what constitutes a condition to terminate a program (reached solution, won't reach solution, want to try something else, ...) but when you see it expressed in a plot you will know it as a termination condition.

Jim Dempsey

[Jeffrey_A_Intel]

Quoting - forall

I think if this facility could be implemented for the Fortran Evaluator it would constitute a very significant improvement. The fact that it already exists for C/C++ would suggest its implementation is feasible.

I agree that this feature would be a significant improvement for Fortran debugging, but the existence of this feature for C/C++ debugging does not at all imply that "its implementation is feasible." Consider that the C/C++ debugger is written by engineerswho have access to all of the internals of Visual Studio; they can make it do what they need it to do. On the other hand, the Fortran Expression Evaluator is an external "add-on" to Visual Studio which has a very narrow, static and ancient interface into Visual Studio. It can only do what that interface allows.

The apparatus required to invoke an user-written procedure "out of line" (the technical term is "inferior call") in a debuggee is extensive and complicated. Just consider: you have to fabricate an execution environment for this new routine which is a duplicate of, but does not interfere with, the existing environment debuggee. Obviously, it can be done but it's unlikely to be possible by the current Fortran Expression Evaluator given the capabilitiesnow available to it.

I've created a feature request for this; reference CQ138600.

[forall]

Quoting - Jeff Arnold (Intel)

I agree that this feature would be a significant improvement for Fortran debugging, but the existence of this feature for C/C++ debugging does not at all imply that "its implementation is feasible." Consider that the C/C++ debugger is written by engineerswho have access to all of the internals of Visual Studio; they can make it do what they need it to do. On the other hand, the Fortran Expression Evaluator is an external "add-on" to Visual Studio which has a very narrow, static and ancient interface into Visual Studio. It can only do what that interface allows.

The apparatus required to invoke an user-written procedure "out of line" (the technical term is "inferior call") in a debuggee is extensive and complicated. Just consider: you have to fabricate an execution environment for this new routine which is a duplicate of, but does not interfere with, the existing environment debuggee. Obviously, it can be done but it's unlikely to be possible by the current Fortran Expression Evaluator given the capabilitiesnow available to it.

I've created a feature request for this; reference CQ138600.

Thanks for your reply Jeff. I recognize Intel Fortran engineers have a more limited access to the VS functionality than the VC++ designers.

(A somewhat limited experience nothwithstanding) I do consider the CVF/IVF strand to be excellent Fortran tools and hope you continue improving the latter. If the requested feature could be implemented it would be great, otherwise "ce la vi".

[Jeffrey_A_Intel]

Quoting - forall

If the requested feature could be implemented it would be great, otherwise "ce la vi".

I prefer emacs myself, butC'est la vie. ;-)

[forall]

Quoting - Jeff Arnold (Intel)

I prefer emacs myself, butC'est la vie. ;-)

hehe, does this mean the next compiler release will correct syntax errors in non-compiled code?
would be of great help to those of us from the phonetic spelling generation ;-)