Can't set a data break point on a real*8

[mford78]

I admit upfront that I do not know if this is an issue with IVF or with MSVS. When either myself, or my coworker try to set a data break point on a real*8 variable (by following the standard procedure for setting a data break point and setting the byte count to 8), we press okay and we are both greeted with a popup informing us that "The breakpoint cannot be set. The hardware does not support monitoring the requested number of bytes."

Some research of mine found that "modern" versions of visual studio handle this by looking at a memory location that is at most size_t in size. If this is the case, then on my 32-bit machine (Core2Duo and Windows XP) it makes sense that I should not be able to look at eight bytes at once. However, on my coworker's 64-bit machine (Xeon W3530 and Windows 7 64-bit), where size_t should be eight bytes (right?), he is getting the same error message when he tries to set a data break point on something eight bytes wide.

This is complicated by the fact that he is switching to VS2k10 and IVF12 from an old Compaq Fortran 6.6 and VS6 environment. He swears that under that older environment (before there was any thought of 64-bit machines) he was able to break on changes in real*8s without issue.

So my question is: is this a Fortran issue, or a Visual Studio issue? If neither, then what hardware does one need now to be able to break on a change in value of a real*8? We can get around this by setting our breakpoint on a change in value of the first four bytes of the real*8, but that doesn't guarantee that we'll get a break when it changes. Thanks for any info people can offer up.

[Steven_L_Intel1]

I think VS changed how it did breakpoints. In the past, it would step by instruction and then test to see if the values changed. Now it uses some sort of hardware detection, and this is independent of language.

The key is that the application needs to be built as a 64-bit application - if you do that, then you can set an 8-byte breakpoint. Remember than when running a 32-bit application, the processor is effectively in 32-bit mode so none of the x64 enhancements are available.

[jimdempseyatthecove]

The VS debugger data break point is 'Break on Memory Write' at location as opposed to memory changed (writes of same value break). Therefore, you only need to have one of the bytes of the data break point reside within the object written. A 32-bit DWORD aligned address that a) extends into a 64-bit QWORD (real*8), b) contained within a 64-bit QWORD, or c) extends from within 64-bit QWORD is sufficient to cause a break on memory written of REAL*8. When you specify the real*8 variable address to VS you typicaly get a 4-byte break variable origined at the address of the REAL*8. This is sufficient to catch memory writes to this real*8. Excepting for write high DWORD, either of two highest WORDs or any of the four highest bytes of the real*8. This type of writes generally come from errant references or corruptions. To track this, you can set two a 4-byte breaks, one at the location of the variable of interest, and one 4 bytes later. (but this would be an exception to the normal debugging requirements)

Jim Dempsey