Debugging x64 code in Visual Studio 2010 doesn't allow one to view 64-bit addresses

mford78 — Fri, 25 May 2012 15:30:11 GMT

I originally posted this a while back in the general IVF forum, but no one was quite sure what to do with it. Now that there is a dedicated debugging forum, I'll try here! Here is a summary of what I found, and what went on:

When I attempt to build our code for x64 architecture through VS and debug it, then view the "Memory windows" during debugging, I get nothing but ??????'s for all addresses and variants of display types.

I can successfully tell the window to display a given address using LOC(variable) (but going by straight memory address gives problems as it will show me 0x7FFFFFFF). LOC(variable) works fine, except that no matter what variable I choose, it shows me nothing. In a possibly related issue, attempting to use data break points results in the breakpoints being skipped entirely.

...

Now, using the immediate window I can get the address of implicitly defined variables, but when I paste it into the memory window I don't think it works quite right. If I want to look at the location of implicit_variable_1, I go to the 'Immediate Window' and type LOC(implicit_variable_1) and get an address, #00000001888EBD20 (which would be a 64-bit address if I am not mistaken). I then go to the memory window and paste this address into the 'Address:' field and the memory window brings up location 0x7FFFFFFF (the 2GB or 32-Bitlimit, if I am not mistaken) and a whole lot of ??????? (the original question that started this thread). If I type the variable name implicit_variable_1 directly into the 'Address:' field, it shows me a memory region starting at 0x00000020 or something equally incorrect (along with said ???????s).

If I switch to the not implicitly defined variable var_1, and I type its name directly into the memory window's 'Address:' field, it pops up with a seemingly correct memory location. One that holds what I am expecting and corresponds to what I get from the 'Immediate Window' using LOC(var_1). For example, if I type var_1 into the Memory Window, I get address 0x0000000186DAF9F4, and when viewed as a real, it shows me the value that var_1 should have. However, if I turn this around and type the address into the 'Address:' field directly, I once again get taken to address 0x7FFFFFFF and see all ???????s. Typing LOC(var_1) in the 'Address:' field takes me to 0x86DAF9F4 (seemingly corresponding 32-bit address, even though it is above the 32-bit addressable space) in the memory region and shows me all ?????????s.

If I attempt to set a data break point on the address of the explicitly defined variable (0x0000000186DAF9F4 or what I presume is its 32-bit equivilent of 0x86DAF9F4) it tells me it is setting a breakpoint "When '0x7FFFFFFF' changes (4 bytes)" which is clearly incorrect.

It seems to me (in my only slightly educated opinion) that there is confustion about 32 and 64-bit applications and addressing schemes. That said, I have no idea if it is a Visual Studio issue, or an IVF issue, or if it is no issue at all and I just have something set incorrectly

Here is a simple program that is able to reproduce this issue:
[fxfortran]program fortBreakTest implicit none ! Variables double precision, dimension (1000000) :: array integer :: i, j, k ! Body of fortBreakTest i = 0 j = 0 k = 0 do i = 1, 1000000 array(i) = i enddo i = 1 j = 2*i do i = 1, 10 k = k + i enddo print*, "I, J, K = ", i, j, k end program fortBreakTest [/fxfortran] In the debugger I have break points on the i=0 and i=1 lines. If I ask for the location of array(1000000) in the Immediate Window, I get
LOC(array(1000000))#0000000140216298

Pasting LOC(array(1000000)) into the Memory Window's 'Address:' field brings up the memory location 0x40216298 and gives me a whole lot of ????????s in the display. Pasting the address (0x0000000140216298) into the Memory Window's 'Address:' field brings up 0x7FFFFFFF and displaysa lot of ???????s.

Entering array(1000000) in the 'Address:' field brings up 0x0000000140216298 and shows the contents of that array element correctly. However, if I take even a single step with the debugger the Memory Window switches from the correct memory location to 0x7FFFFFFF and displays ????????s all the way around.

Hopefully this will allow you to reproduce what I am encountering and suggest a fix/way around it. Thanks again for your help.

...

As a quick update, creating a very nearly identical program in C++ (compiled with Visual Studio's C++ compiler, not Intel's) and running the exact same tests worked just fine. The Memory Window in C++ debuggerhappily accepted addresses in 64-bit form, both if input directly, or as the address of the array variable.

...

This occurs(ed) with both IVF 12.0.4.196 and the latest we've tried, 12.1.3526.2010.Thanks for any help people can provide, this bug makes it near impossible for us to begug the 64-bit version of our application and we'd really like to have that ability. I can post screenshots of this behavior if it will help.

Debugging x64 code in Visual Studio 2010 doesn't allow one to v

mecej4 — Sat, 26 May 2012 08:47:29 GMT

This may be one of those 'Fortran culture' versus 'C culture' issues.

> Pasting LOC(array(1000000)) into the Memory Window's 'Address:' field brings...

If, in the Memory window, you type

array(1000000)

instead of either LOC( the same variable ) or the 64 bit hex address value given by the Immediate window, the correct value is shown.

This may be a little irritating if you are used to typing in 0xnnnnnnnnnnnnnnnn when debugging a C program, and it can even be a significant problem when debugging mixed C and Fortran codes. However, for a pure Fortran program, just typing the subscripted variable works, which suggests that the GUI evaluates what you type in as an address expression without dereferencing that address.

Debugging x64 code in Visual Studio 2010 doesn't allow one to v

Georg_Z_Intel — Thu, 31 May 2012 15:17:09 GMT

Hello,

sorry to hear that you did not get help instantly. Thanks to your good description I was able to reproduce the problem and can confirm this as bug in the Fortran Expression Evaluation (FEE) which comes with our integration.
A defect was filed (DPD200288770) and engineering is already working on it. I'll let you know as soon as it is fixed.

Best regards,

Georg Zitzlsberger

Debugging x64 code in Visual Studio 2010 doesn't allow one to v

Georg_Z_Intel — Mon, 11 Jun 2012 16:50:20 GMT

Hello,

I'm happy to announce that we'll have this problem fixed with Intel Composer XE 2011 Update 11. It will be available in a couple of weeks.

Best regards,

Georg Zitzlsberger

topic Debugging x64 code in Visual Studio 2010 doesn't allow one to view 64-bit addresses in Software Archive

Debugging x64 code in Visual Studio 2010 doesn't allow one to view 64-bit addresses

Debugging x64 code in Visual Studio 2010 doesn't allow one to v

Debugging x64 code in Visual Studio 2010 doesn't allow one to v

Debugging x64 code in Visual Studio 2010 doesn't allow one to v