Issues Debugging Variables in Common Block Defined Elsewhere

[weaver__darren]

After upgrading from the Intel Fortran Compiler 2011 to 2019 (and now 2020), I'm having an issue in the debugger, where it appears to get the wrong addresses (and thus, wrong values) for my variables. My variables are defined as an equivalence of a location in a variable defined in a COMMON block. Most of my calculational code is written in FORTRAN. These files are compiled into a static library.

      byte g01__(0:753663)
      common/GLOBAL01/g01__

      real*4 MYVAR(8,73)
      equivalence (MYVAR,g01__(417984))

The GLOBAL01 area is defined in an assembly file as follows. This code is linked into the executable, which is built from a C project that links in the static library.

	.486P
	.MODEL FLAT
	........
	PUBLIC	_GLOBAL01
	........
	_GLOBAL01=30010000H
	........
	END

When I print the locations from my code, I get the correct addresses:

        WRITE(*,'(A,Z8,A,Z8)') "Loc(MYVAR) = ", LOC(MYVAR), 
     &                         ", Loc(g01__) = ", LOC(g01__)

     Loc(MYVAR) = 300760C0, Loc(g01__) = 30010000

However, in the debugger, I seem to get the wrong locations:

		loc(g01__)	#30150000	INTEGER(4) 
		loc(MYVAR)	#301B60C0	INTEGER(4) 

Everything worked right in 2011 (with VS2010). Is there something that I need to do as part of the upgrade process to get this correct, or is this an issue in the debugger? Is there a method to debug this potential issue?

[mecej4]

Unless you have taken special steps to tell the linker to mark the EXE for execution at a fixed address, or configure your debugger to load the EXE at a specified address, the debugger may load the EXE with different base addresses at different times. This is normal. Note that the difference between the two locations concerned (g01__ and MYVAR) is, in both the cases that you wrote about, Z'660C0', which in decimal is 417984.

[weaver__darren]

It seems that the linker is building it correctly, as the WRITE statement shows g01__ in the location that we defined GLOBAL01 to be. Also, when I debug the C portion of the code, it shows GLOBAL01 in the correct location. It's just the FORTRAN side in the debugger, where g01__ and GLOBAL01 (0x30150000, but changes on a recompile) don't match the address that we've defined for GLOBAL01 (0x30010000). I've also used the Memory window in the debugger to verify that memory location 0x30010000 contains the correct data for GLOBAL01.

We don't execute the program from the debugger, but rather attach to an existing process. I've attached to the statement right after the WRITE statement, and a LOC() in the debugger doesn't match what was just written to the console. Is there something I need to do to get the FORTRAN debugger to attach to the EXE at the specified address?

Edit: Attempted to clarify the first paragraph.

[jimdempseyatthecove]

>>Is there a method to debug this potential issue?

associate(debug_g01__ => g01__, debug_MYVAR => MYVAR)
... ! use the debug_... variable to debug
end associate

Jim Dempsey

[weaver__darren]

I found a tool to dump the PDB file to a text file. When I look at the PDB information for that module, it looks like the symbols match the expected location (see below). The types appear to be correct in the PDB also.

(000328)  S_LDATA32: [000B:30010000], Type:             0x118D, G01__
(000350)  S_LDATA32: [000B:300760C0], Type:             0x12EB, MYVAR

As mentioned in the root post, the code runs ok and the variables are mapped to the correct location based on the WRITE statement. It's only the debugger that seems to have the wrong addresses for the variables, and only in the FORTRAN code.

I'm trying to figure out if this is an error in the debugger, or something that changed between Intel Fortran Compiler versions 2011 and 2020.