Fortran DLL's call stack in XE2013 debugger weird compared to XE2011 -- integration problem?

[Elias_Sabbagh]

Hi folks-

Win7 x64, XE 2013 is being used to debug into a Fortran DLL, where the main program is written using Delphi 2009.  The main app manually exports some Delphi routines by passing their addresses to the Fortran DLL, which imports them using Cray pointers and interface blocks.  I have all of the calling conventions worked out, and Delphi routines can call the Fortran DLL routines, and vice versa.  After a lot of help from this forum, I even got the parameter passing correct...  I'm very confident that this technique works.

Occasionally I need to debug the DLL, as you might expect.  To do this I usually fire up the main app from within Delphi 2009, detach Delphi's debugger, attach XE's debugger, and set my breakpoints.  The breakpoints are disabled until the DLL is loaded at a later point in the app's execution, but everything works smoothly once the DLL is loaded.  The DLL itself is working consistently -- there's no showstopper bug, and, while I don't like the numbers that my buggy DLL spits out, at least I can trace the code and find out where my math is wrong.

When I used to debug the DLL using XE 2011 running on WinXP x86, the debugger would show the local variables correctly change as I stepped through the code.  Now that I've moved to XE 2013 on Win7 x64, the debugger seems "off" -- the locals don't change at the right time, or the debugger thinks that the next local changed instead, or the values are just nonsensical.  Classic stack corruption/parameter size problem, right?  Except that once those local values are copied over to something allocated on the heap, the values look correct.  Sometimes also, a "weird looking" local is passed down to a subroutine, and then the value appears to be correct to that subroutine.  It leads me to believe that there might be an integration issue with Visual Studio or something.  Looking at the call stack dropdown shows the listed parameters for the subroutines with the correct sizes, but interestingly, a leading comma before the first parameter -- almost as if VS thinks that theres a hidden parameter in the first position.  Is there something "shifting" the parameters by a few bytes?  I don't think Delphi does anything nutty to STDCALL routines, but I don't know where to look next.  Remember that I've already had this code working in the old toolchain, and I'm pretty confident that Delphi and Fortran are interfacing correctly.

What else might cause this behavior?

Thanks,

Elias Sabbagh

[IanH]

Perhaps this http://software.intel.com/en-us/forums/topic/328615

[Elias_Sabbagh]

It sure sounds like it! I'm glad I'm not going crazy -- and I'll be glad once Intel rolls out the first update...