Debugging from managed code

Debugging from managed code

Hi,

I am trying to debug a fortran code from managed code. I have found 2 situations at which I am not able to watch some variables:

module LibToDebug_m

	  use iso_c_binding

	  implicit none
  integer, private, parameter :: SIZE = 2
contains

	  subroutine DebugMe0(a, array1, array2)

	    integer, intent(in)       :: a

	    real*8, dimension(:)      :: array1

	    real*8, dimension(SIZE)   :: array2
    write(*,'(A)') 'native::DebugMe0'

	    write(*,'(A)') 'breakpoint 0'
  end subroutine DebugMe0

	  subroutine DebugMe1(a, array1, array2)

	    integer, intent(in)       :: a

	    real*8, dimension(:)      :: array1

	    real*8, dimension(SIZE)   :: array2
    integer                   :: b

	    integer                   :: c

	    integer                   :: index
    write(*,'(A)') 'native::DebugMe1'
    b = 0

	    c = a + b

	      

	    index = 0

	    do

	      index = index + 1

	      if (index > SIZE) exit

	      write(*,'(A)') 'breakpoint 1'

	    end do
  end subroutine DebugMe1

	  

	  

	  subroutine DebugMe2(a, array1, array2)

	    integer, intent(in)       :: a

	    real*8, dimension(:)      :: array1

	    real*8, dimension(SIZE)   :: array2
    integer                   :: b

	    integer                   :: c

	    integer                   :: index
    write(*,'(A)') 'native::DebugMe2'
    b = 0

	    c = a + b

	      

	    index = 0

	    do index = 1, SIZE

	      write(*,'(A)') 'breakpoint 2'

	    end do
  end subroutine DebugMe2

	  subroutine DebugMeExternal(a) bind(c, name="DebugMeExternal")

	    !DEC$ ATTRIBUTES DLLEXPORT :: DebugMeExternal

	    integer(kind=c_int), value, intent(in)      :: a
    real*8, dimension(SIZE)                     :: array1, array2
    write(*,'(A)') 'native::DebugMeExternal'
    array1(1) = 1

	    array1(2) = 2

	    array2(1) = 3

	    array2(2) = 4
    call DebugMe0(a, array1, array2)

	    call DebugMe1(a, array1, array2)

	    call DebugMe2(a, array1, array2)
  end subroutine DebugMeExternal
end module LibToDebug_m

At a breakpoint 0 I cannot watch values in the array1. Also additional .tmp.0.ARRAY1 variable is available in the stack, probably it contains size of the array1;

At a breakpoint 1 I cannot watch array1, b and c.

At a breakpoint 2 I cannot watch only array1. b and c are available. I guess they style of a do-loop matters for debugging.

Are these Intel compiler's or VS's issues? Is there a way to fix them by simply changing the settings? If not are you planning to fix it in the next release? :)

Versions: XE 13.1, Visual studio 2012 Update 4, .NET 4.5

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

What build options are you using to build this DLL? I assume you're able to stop at breakpoints in the DLL (which implies that you have enabled unmanaged code debugging in the managed code project.)

Retired 12/31/2016

compiler's options: /nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc110.pdb" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

linker's options: /OUT:"LibToDebug.dll" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"LibToDebug.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:LibToDebug.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:LibToDebug.lib" /DLL

Yes, unmanaged code debugging is enabled.

Which managed language are you calling this from? So far I can't reproduce the problem. Please attach a ZIP of a small but complete managed code project that calls this routine and shows the issue. I'll note that most of the managed languages want a STDCALL interface when calling into a DLL, and you aren't providing that. In this environment, you don't get the protection of name decoration, so a mismatch like this isn't obvious, but it can lead to stack corruption. (Note that in our implementation, you can't mix STDCALL with BIND(C).)

Retired 12/31/2016

It is C#.

I have attached a small project for Visual Studio 2012 and a few screenshots.

 

 

Attachments: 

Ah, the screenshots were very helpful. You're not getting the Fortran debug support there - the debugger thinks you're in C (or maybe C#) code. Let me try your ZIP.

Retired 12/31/2016

Very interesting. I can reproduce this with your C# example as well as another one I have. But a VB.NET example doesn't behave the same way. Visual Studio is preventing the Fortran debugger support from being used here - why it should do that for C# and not VB, I don't know. It's not a compiler issue and I don't know if it's anything we can control. I will ask our VS debugging experts for their thoughts.

Retired 12/31/2016
Best Reply

To enable the Fortran debugger features for mixed language program debugging under VS2012/2013:  open the Tools ->Options and under the Debugging ->General  properties clear the Managed C++ Compatibility Mode (it's "Use Managed Compatibility Mode" in VS2013) check box.

Retired 12/31/2016

Quote:

Steve Lionel (Intel) wrote:

To enable the Fortran debugger features for mixed language program debugging under VS2012/2013:  open the Tools ->Options and under the Debugging ->General  properties clear the Managed C++ Compatibility Mode (it's "Use Managed Compatibility Mode" in VS2013) check box.

 

It works. Thank you!

Leave a Comment

Please sign in to add a comment. Not a member? Join today