topic Ah, the screenshots were very in Intel® Fortran Compiler

Debugging from managed code

Marat_S_1 — Fri, 13 Dec 2013 18:21:08 GMT

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:

[fortran]

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

[/fortran]

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

What build options are you

Steven_L_Intel1 — Fri, 13 Dec 2013 18:55:23 GMT

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.)

compiler's options: /nologo

Marat_S_1 — Mon, 16 Dec 2013 13:21:22 GMT

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

Steven_L_Intel1 — Mon, 16 Dec 2013 15:02:36 GMT

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).)

It is C#.

Marat_S_1 — Mon, 16 Dec 2013 16:30:22 GMT

It is C#.

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

Ah, the screenshots were very

Steven_L_Intel1 — Mon, 16 Dec 2013 18:25:30 GMT

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.

Very interesting. I can

Steven_L_Intel1 — Mon, 16 Dec 2013 19:12:44 GMT

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.

To enable the Fortran

Steven_L_Intel1 — Mon, 20 Jan 2014 15:29:37 GMT

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.

Quote:Steve Lionel (Intel)

Marat_S_1 — Mon, 20 Jan 2014 15:53:15 GMT

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!