Debugging the executable built with the command mentioned above via sdbg64 8.50 results in following obscurities:

Source file test_clearwin_info.for is not shown
Entering CTRL-G + character "4" makes the debugger show the source file
Trying to set a breakpoint via F2 in line 3,4,5 results in error message "This line cannot be breakpointed"
Having selected menu Window, submenu Common Block makes sdbg64 hang

Using sdbg64 8.40 instead of 8.50 the source window is shown and I can set breakpoints in the lines mentioned above. However, the Common Block submenu behaves strange as described above. Moreove I observed that the Common Block submenu does not appear in the Window menu of the 32 bit version of sdbg (8.40 and 8.50).

There is something very strange going on there. I can have it happen but it happens in various versions of sdbg64 - (8.50 and 8.30 for example). You say you can get it to work with version 8.40 but I couldn't.

in the DOS window which I used for building test_clearwin_info.exe with respect to ftn95 version 8.50, environment variable SOURCEPATH was not set. Hence I set it to the absolute path of the directory the source to be compiled was located in. Now when I executed

Code:

sdbg64 test_clearwin_info.exe

the source was displayed as expected and I could set breakpoints.

This was even true if I "unset" SOURCEPATH again (via command "set SOURCEPATH=").

thanks for the new version (8.51.0) of ftn95.exe. Now in sdbg64 the sources of my test sample are shown as expected without variable SOURCEPATH having been set and I can set breakpoints, as well.

There is still another question I raised which, however, is of minor importance to me: what about menu Window, submenu "Common Blocks" in sdbg64? I currently do not know its meaning and sdbg64 hangs if I select it.

Dietmar, in SDBG64 version 8.40.1, the Common Blocks pop up simply shows the range of addresses occupied by common blocks, if any are declared. After viewing that pop up, I have no problems with setting break points, stepping through the program and viewing variable values.

With most compilers, the addresses of common blocks may be obtained by telling the linker to produce a map file. SLINK64, on the other hand, will not assign addresses to common blocks at link time. Thus, being able to obtain the addresses of common blocks can be useful at run time when debugging at the assembler level.

PS: I can reproduce the problem described by Dietmar when I start a program that does not contain common blocks in SDBG64 8.40.1 and click on Window->Common Blocks.

Last edited by mecej4 on Tue Jun 04, 2019 12:19 pm; edited 1 time in total

to the code of test_clearwin_info.for); compiling/linking with ftn95 (version 8.51.0) works and I can see the Common Block Window as described by mecej4. Now if I decomment the common block line in the code again and compile/link again, sdbg64 works with respect to the Common Block menu: no hanging any more if I select the common block menu. This makes me astonish, for the original application when comiled/linked for the first time had hung in this situation.