I have a solution with about 22 FORTRAN source files.
Just wondering why it can exit when NONE of them are a program file, all subroutines
Its behaving as if there there is only TWO statements, as if program - - - - END are the only two statements.
I did an exhaustive search, but there are NO program statements anywhere .
If there arent any - - - then why would it go anywhere at all ?
Is there a way to breakpoint the FIRST executable statement with knowing where it is ?
Is there a way to delele all the object files, and have it start from scratch ?
The following is a valid program:
If you have built a debug version successfully, F11 will launch it and stop at the first executable statement that is encountered in a subprogram that has debug symbols in the OBJ file.
You have been using Visual Studio and Intel Fortran for over a decade. This should all be under your belt by now!
>>I have a solution...NONE of them are a program file, all subroutines
If that were true, the build process would not produce an executable.
iTS TRUE, i HAVE BEEN USING THE FORTRAN SINCE 2010.
However, I had to go back, since I cant get the more up-to-date VS and parallel studios to work.
Going to the first EXECUTABLE statement does not help, since
it does not tell me where is went.
If there are two starting points, how do I find where the they BOTH are ?
Apparently not having a PROGRAM statement in a routine can generate a starting point.
So it makes it difficult, to find where it actually IS starting.
>>Apparently not having a PROGRAM statement in a routine can generate a starting point.
I tested this premise.
You apparently have a free-standing end statement
end ! alone
end ! without or with subroutine foo
If you set a breakpoint in a subroutine that you know it is called, launch the debugger. When it stops on that breakpoint, the caller stack is displayed and I think that you will find the main caller at the top.
I understand the requirement to ONLY have one starting entry point.
However, finding out WHERE they are is a major challege, because of the complexity of the program.
I dont think the debugger allows me by default, to breakpoint the FIRST EXECUTABLE statement.
of coirse it wont run at all, if there is an ambiguity.
I was wondering if I could pay someone for a one-on-one consultation?
I am trouble getting around the complexities of the LATER VS and Visual parallel integration.
Seems to be an ongoing issue.
Beats waiting around for 2 days, anyway.
I think you have a priority customer assist, but not sure how to get that.
If the program is a console application, the entry point is the main program (global symbol _MAIN). If it is a "Windowing Application", it is the WinMain function. Of all the things that can be difficult to locate, this is not one of them.
You don't need to set a beakpoint in the first executable statement but only in a statement you know it is executed. Let the debugger go to that statement and then the stack of the calls from the entry point will be displayed.
But, as Lionel said, that's only pertinent if it is a console application. If not search the WinMain function.
An another idea may be adding a source file to your project containing an empty program statement. The linker may tell you which obj files are in conflict.
I am not sure on Linux, but on Windows with Microsoft Visual Studio,
! nullProgram.f90 subroutine foo end ! or end subroutine foo end ! *** extra END serves as PROGRAM
from the IDE after Build (iow when program not running):
Debug | Step Into
This will break at the C Runtime Library initialization entry point.
Open the Disassembly window. At the top of that window is an Address edit box. Enter as address:
--- C:\test\nullProgram\nullProgram\nullProgram.f90 ---------------------------- ! nullProgram.f90 subroutine foo 00E21002 in al,dx 00E21003 sub esp,28h 00E21006 push eax 00E21007 push edi 00E21008 push ecx 00E21009 lea edi,[ebp-28h] 00E2100C mov ecx,0Ah 00E21011 mov eax,0CCCCCCCCh 00E21016 rep stos dword ptr es:[edi] 00E21018 pop ecx 00E21019 pop edi 00E2101A pop eax end ! or end subroutine foo 00E2101B mov eax,0E271A0h 00E21020 mov edx,eax 00E21022 mov ecx,ebp 00E21024 push edx 00E21025 push eax 00E21026 call _RTC_CheckStackVars (0E23C80h) 00E2102B pop eax 00E2102C pop edx 00E2102D add esp,28h 00E21030 cmp ebp,esp 00E21032 call _RTC_CheckEsp (0E23CE0h) 00E21037 leave 00E21038 ret end ! *** extra END serves as PROGRAM 00E21039 push ebp 00E2103A mov ebp,esp 00E2103C sub esp,2Ch 00E2103F push eax 00E21040 push edi 00E21041 push ecx 00E21042 lea edi,[ebp-2Ch] 00E21045 mov ecx,0Bh 00E2104A mov eax,0CCCCCCCCh
The cursor is positioned at the line following end ! *** extra END
I unferstand about the WinMain function -
But the debugger does not allow me to set a breakpoint there.
It never appears in any source code, right ?
In a console application, it must exist a main program somewhere in one source file .
[program] ! optional ...some code end
In a windowed application, it must exist a winmain function somewhere in one source file.
integer*4 function winmain(hinstance,hprevinstance,lpszcmdline, ncmdshow ) ...some code winmain=... end function
So you can set a breakpoint in a statement in the winmain function.
Is there external libraries or object files linked to your project? If so, the program or the winmain function may be declared in it.
>>But the debugger does not allow me to set a breakpoint there....
>>It never appears in any source code, right ?
This is why you do not use the context of the (a) source code window to set the break point.
Instead, use the context of the Disassembly Window.
Using MS VS
Debug | Step Into | Disassembly window tab | Address: _UNNAMED_MAIN$$ or other name
Debug | Step Into | Debug | Windows | Breakpoints | New | Function Breakpoint | Function Name: _UNNAMED_MAIN$$ | Continue
Adding to what Jim recommended: note that after starting a debug run with F11, you can bring up the Breakpoints panel by typing Ctrl-B. You can then type in MAIN__ as a function breakpoint, without having to know the name of the file wherein that symbol resides.