- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page