Debugging fortran

[JoachimB]

For some obscured reason, I'm working on a project where I'm trying to get an old fortran program to come to live again. Now I'm using codeblocks and the GCC (G77). The program actually runs and I can debug it in codeblocks. There is one problem though; The debugger (gdb) knows where in the code in it is and breakpoints works. It also knows the path to the source file but, -and here it comes, the IDE does not point out which line it is on. (Actually, I'm using the IDE to set the breakpoint so that direction is working)

My output looks like below;

Selecting target: Debug
Compiling: done
Adding source dir: C:\Projects\Tiny\fello\
Adding source dir: C:\Projects\Tiny\fello\
Adding file: bin\Debug\fello.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 5.2.1
At C:/Projects/Tiny/fello/tiny.f:4   :lol:
 

The small program I used here looks like this

      PROGRAM TINY 
      CHARACTER ODOR*2
      WRITE(UNIT=*,FMT=*)'Hello world'
      WRITE(UNIT=*,FMT=*)'Hello hello'   
      READ (UNIT=*,FMT=995) ODOR
      WRITE(UNIT=*,FMT=*)'Good bye'
995 FORMAT(A2)
      END

The compiler output looks like

-------------- Build: Debug in fello ---------------
mingw32-g++.exe -Wall -g  -I- -I. -IC:\MingW\include  -c tiny.f -o obj\Debug\tiny.o
mingw32-g++.exe -LC:\MinGW\lib  -o bin\Debug\fello.exe obj\Debug\tiny.o    ..\..\..\SW_Dev\f2c\libf2c\Libf2c.a
Process terminated with status 0 (0 minutes, 2 seconds)
0 errors, 0 warnings
 
The source file is in the same directory as the cbp file and it is a straight wizard generated console application where I only have added the libf2, removed the main.cpp file and finally added the tiny.f file which is recognized as an other file by the Ide. I have manually marked the tiny.f for compiling and linking.

-Any suggestions on how to get the IDE to point out where the program stopped due to the breakpoint? If someone points me in the right direction I might be able to find a solution in the code (Probably I'm saying to much now)

Joachim

Impressive piece of work, Code::Blocks!

[mandrav]

You should enable the debugger's debug log (in debugger options) and paste its output here.

[MortenMacFly]

Hmmm... It works for me (see the screenshot).
I wonder why you compile your program with G++ instead of G77... Did you find:
http://wiki.codeblocks.org/index.php?title=Installing_Fortran_Compiler
With regards, Morten.

[attachment deleted by admin]

[JoachimB]

I did set "Display debugger´s log and got;

-------------------------------------------
Command-line: c:\dev-cpp\bin\gdb.exe -nx -fullname  -args bin/Debug/fello.exe
Working dir : C:\Projects\Tiny\fello\
> set prompt (gdb)
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) (gdb)
> set confirm off
(gdb)
> set width 0
(gdb)
> set height 0
(gdb)
> set breakpoint pending on
No symbol "breakpoint" in current context.
(gdb)
> set print asm-demangle on
(gdb)
> set new-console on
(gdb)
> set disassembly-flavor intel
(gdb)
> directory C:/Projects/Tiny/fello/
(gdb)
> delete breakpoints
(gdb)
> break tiny.f:4
Breakpoint 1 at 0x40131b: file tiny.f, line 4.
(gdb)
> run
Breakpoint 1, MAIN__ () at tiny.f:4
C:/Projects/Tiny/fello/tiny.f:4:84:beg:0x40131b
Current language:  auto; currently fortran
(gdb)
--------------------------------------------

and

-----------------------------------------------------------------------------
[21:35:58.919]: Initialize EditColorSet .....
[21:35:58.939]: Loading lexer_angelscript.xml
[21:35:59.009]: Loading lexer_batch.xml
[21:35:59.029]: Loading lexer_cg.xml
[21:35:59.560]: Loading lexer_cpp.xml
[21:35:59.630]: Loading lexer_css.xml
[21:35:59.720]: Loading lexer_d.xml
[21:35:59.830]: Loading lexer_diff.xml
[21:35:59.860]: Loading lexer_f77.xml
[21:35:59.910]: Loading lexer_glsl.xml
[21:36:00.060]: Loading lexer_gm.xml
[21:36:00.090]: Loading lexer_hitasm.xml
[21:36:00.131]: Loading lexer_lua.xml
[21:36:00.161]: Loading lexer_masm.xml
[21:36:00.441]: Loading lexer_matlab.xml
[21:36:01.963]: Loading lexer_nsis.xml
[21:36:02.464]: Loading lexer_OgreCompositor.xml
[21:36:02.494]: Loading lexer_OgreMaterial.xml
[21:36:02.514]: Loading lexer_prg.xml
[21:36:02.604]: Loading lexer_python.xml
[21:36:02.995]: Loading lexer_rc.xml
[21:36:03.045]: Loading lexer_xml.xml
[21:36:03.095]: Initialize EditColorSet: done.
[21:36:03.465]: Loading toolbar...
[21:36:03.746]: AStylePlugin: loaded
[21:36:03.786]: Autosave: loaded
[21:36:04.126]: CBProfiler: loaded
[21:36:04.687]: ClassWizard: loaded
[21:36:04.777]: Concurrent threads for pool set to 1
[21:36:04.927]: CodeCompletion: loaded
[21:36:05.088]: CodeStatistics: loaded
[21:36:05.568]: Added compiler "GNU GCC Compiler"
[21:36:05.568]: Added compiler "Microsoft Visual C++ Toolkit 2003"
[21:36:05.568]: Added compiler "Borland C++ Compiler 5.5"
[21:36:05.568]: Added compiler "Digital Mars Compiler"
[21:36:05.568]: Added compiler "OpenWatcom (W32) Compiler"
[21:36:05.568]: Added compiler "Intel C/C++ Compiler"
[21:36:05.568]: Added compiler "SDCC Compiler"
[21:36:05.568]: Added compiler "GNU GDC Compiler"
[21:36:05.568]: Added compiler "Digital Mars D Compiler"
[21:36:05.568]: Added compiler "GNU ARM GCC Compiler"
[21:36:05.578]: Added compiler "f2c"
[21:36:05.578]: Compiler: loaded
[21:36:05.598]: copystrings: loaded
[21:36:06.279]: Debugger: loaded
[21:36:06.700]: FilesExtensionHandler: loaded
[21:36:07.191]: DevPakUpdater: loaded
[21:36:07.211]: DragScroll: loaded
[21:36:07.321]: Source Exporter: loaded
[21:36:07.481]: HelpPlugin: loaded
[21:36:07.671]: cbKeyBinder: loaded
[21:36:08.152]: PluginWizard: loaded
[21:36:08.212]: Wizard: loaded
[21:36:08.693]: ToDoList: loaded
[21:36:08.763]: wxSmith: loaded
[21:36:08.763]: wxSmithMime: loaded
[21:36:08.833]: wxSmithWizard: loaded
[21:36:08.853]: WindowsXPLookNFeel: loaded
[21:36:08.863]: Source code formatter (AStyle) plugin loaded
[21:36:09.654]: Autosave plugin loaded
[21:36:09.654]: Code profiler plugin loaded
[21:36:09.654]: Class wizard plugin loaded
[21:36:11.046]: Code completion plugin loaded
[21:36:11.046]: Code Statistics plugin loaded
[21:36:11.287]: Compiler plugin loaded
[21:36:11.287]: Copy Strings to clipboard plugin loaded
[21:36:11.777]: Debugger plugin loaded
[21:36:11.777]: Files extension handler plugin loaded
[21:36:11.787]: Dev-C++ DevPak updater/installer plugin loaded
[21:36:11.787]: DragScroll plugin loaded
[21:36:11.787]: Source Exporter plugin loaded
[21:36:11.787]: Help plugin plugin loaded
[21:36:11.787]: Keyboard shortcuts plugin loaded
[21:36:11.787]: Plugin wizard plugin loaded
[21:36:12.348]: Project wizard added for 'Console application wizard'
[21:36:12.348]: Generic wizard plugin loaded
[21:36:12.769]: Project wizard added for 'Irrlicht project wizard'
[21:36:12.939]: Project wizard added for 'Ogre project wizard'
[21:36:13.049]: Project wizard added for 'wxWidgets application wizard'
[21:36:13.169]: Project wizard added for 'D application wizard'
[21:36:13.179]: To-Do List plugin loaded
[21:36:14.571]: wxSmith plugin loaded
[21:36:14.571]: wxSmith - MIME plugin plugin loaded
[21:36:14.571]: wxSmith - Project Wizard plugin plugin loaded
[21:36:14.571]: Windows XP Look'n'Feel plugin loaded
[21:36:14.942]: Initializing plugins...
[21:36:14.972]: Running startup script
[21:37:13.266]: Loading project file...
[21:37:13.296]: Parsing project file...
[21:37:13.296]: Loading target Debug
[21:37:13.296]: Loading target Release
[21:37:13.296]: Loading project files...
[21:37:13.296]: 2 files loaded
[21:37:13.296]: Done loading project in 30ms
[21:37:13.296]: Project's base path: C:\Projects\Tiny\fello\
[21:37:13.306]: Project's common toplevel path: C:\Projects\Tiny\fello\
[21:37:13.326]: project data set for C:\Projects\Tiny\fello\tiny.f
[21:37:13.326]: Top Editor: C:\Projects\Tiny\fello\tiny.f
[21:37:13.336]: Add project fello in parsing queue
[21:37:40.976]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:37:40.976]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:37:40.976]: Scanned 0 files for #includes, cache used 1, cache updated 0
[21:37:40.976]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:37:40.976]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:37:40.986]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:37:40.986]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:29.798]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:29.808]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:29.808]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:29.808]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:32.532]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:32.532]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:32.542]: Scanned 0 files for #includes, cache used 0, cache updated 0
[21:40:32.542]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:10:22.837]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:10:22.837]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:10:22.837]: Scanned 0 files for #includes, cache used 1, cache updated 0
[22:10:22.837]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:10:22.837]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:10:22.837]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:10:22.837]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:11.187]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:11.197]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:11.197]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:11.208]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.136]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.457]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.457]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.457]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:24.457]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:31.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:31.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:31.146]: Scanned 0 files for #includes, cache used 1, cache updated 0
[22:16:31.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:31.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:31.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:16:31.146]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:18:21.495]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:18:21.495]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:18:21.495]: Scanned 0 files for #includes, cache used 1, cache updated 0
[22:18:21.495]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:18:21.495]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:18:21.495]: Scanned 0 files for #includes, cache used 0, cache updated 0
[22:18:21.495]: Scanned 0 files for #includes, cache used 0, cache updated 0
-----------------------------------------------------------------------------

I also right now tried using the g77 compiler according to the advice in the other reply. (Thanks) It did not help though. Still the same. Missing that little arrow

[MortenMacFly]

mandrav: I think he is right. Why it works for me is because I'm usually mixing Fortran and C/C++ programs together using the G2C library. Thus the source is converted into C and than translated. So debugging works for me on a "C" level. If I compile a "pure" (native) Fortran application is doesn't work for me, too... I never tried that before... :oops:
With regards, Morten.

Edit: I guess the important part of JoachimB's output is:

Code

> break tiny.f:4
Breakpoint 1 at 0x40131b: file tiny.f, line 4.
(gdb)
> run
Breakpoint 1, MAIN__ () at tiny.f:4
C:/Projects/Tiny/fello/tiny.f:4:84:beg:0x40131b
Current language:  auto; currently fortran
(gdb)

[JoachimB]

How do you mean, a mixed fortran / c++ project?
Earlier, I used to use f2c and converted to c files which I made a project of. Then I could debug the c-code of course. But from your screenshot, it looks like you are debugging the fortran code itself. -What does your project look like? After installing G77 according to your wiki page, I have the following build log

-------------- Build: Debug in Fello2 ---------------
g77.exe -Wall -g  -I- -I. -IC:\MingW\include  -c main.f -o obj\Debug\main.o
g77.exe -LC:\MinGW\lib  -o bin\Debug\Fello2.exe obj\Debug\main.o   -lg2c -lstdc++ 
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

[MortenMacFly]

How do you mean, a mixed fortran / c++ project?

Nope, you are completely right. I have used my Fortran template and just adjusted the main.f file in it. Thus I did not have a "native" Fortran application for the screenshot. Just forget about that post of mine. Sorry.
With regards, Morten.

[Michael]

> set prompt (gdb)
GNU gdb 5.2.1

Hello,

You should use GDB 6.3 and not 5.2.1.

Best wishes,
Michael

[JoachimB]

Thanks Mikael, I tried but it makes no difference

Command-line: C:\MinGW\bin\gdb.exe -nx -fullname  -args bin/Debug/Fello2.exe
Working dir : C:\Projects\Tiny\Fello2\
> set prompt (gdb)
GNU gdb 6.3  :shock:
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) (gdb)
> set confirm off
(gdb)
> set width 0
(gdb)
> set height 0
(gdb)
> set breakpoint pending on
(gdb)
> set print asm-demangle on
(gdb)
> set new-console on
(gdb)
> set disassembly-flavor intel
(gdb)
> directory C:/Projects/Tiny/Fello2/
(gdb)
> delete breakpoints
(gdb)
> break main.f:4
Breakpoint 1 at 0x40131b: file main.f, line 4.
(gdb)
> run
Breakpoint 1, MAIN__ () at main.f:4
C:/Projects/Tiny/Fello2/main.f:4:84:beg:0x40131b  --It knows right :shock:
Current language:  auto; currently fortran
(gdb)

[MortenMacFly]

Thanks Mikael, I tried but it makes no difference

It doesn't depend on the debugger's version. I guess it has to do with the parsing of the debugger's output. This is "optimised" for C/C++ code. If you have a hello world C++ application the output looks different:

Code

> break main.cpp:5
Breakpoint 1 at 0x401408: file main.cpp, line 5.
(gdb)
> run
Breakpoint 1, main () at main.cpp:5
C:/DOKUME~1/morten/Desktop/haha/main.cpp:5:38:beg:0x401408
(gdb)

...again in comparision, here is the fortran's output:

Code

> break main.f:4
Breakpoint 2 at 0x40131b: file main.f, line 4.
(gdb)
> run
Breakpoint 2, MAIN__ () at main.f:4
C:/DOKUME~1/morten/Desktop/huhu/main.f:4:81:beg:0x40131b
Current language:  auto; currently fortran
(gdb)

I've had a look at it already but fall asleep yesterday... ;-) Give me some time.
...or I'm sure mandrav knows - he wrote the debugger's parser.
With regards, Morten.

[mandrav]

Code

At C:/Projects/Tiny/fello/tiny.f:4

This line in the debugger's log, shows that the breakpoint was actually seen by C::B (this is a C::B message). So, if there is no marker for the active line, it has to do with the editor. Either the debugger failed to access the cbEditor* holding the file or the editor's markers are not setup correctly.

Morten,

I don't know fortran neither I have it installed. So I 'm gonna need your help on this.
The problem must be inside DebuggerGDB::SyncEditor() (debuggergdb.cpp). Can you put a breakpoint in there and see what's going on when the breakpoint hits?

Hint of the day: did you know that you can examine previous frames (caller functions) by switching to them (right click on the backtrace and choose "switch")?

[MortenMacFly]

So I 'm gonna need your help on this.

...got it: The problem is indeed inside DebuggerGDB::SyncEditor. The issue lies in the following lines of code:

Code

    FileType ft = FileTypeOf(filename);
    if (ft == ftOther)
        return; // don't try to open unknown files

Since for a fortran (*.f) file type the "if" statement is true, DebuggerGDB::SyncEditor just returns and nothing happens.
I hope you have an idea what to do. I'm not sure whether it makes sense just to remove that "if" statement? ...or should we add another file type "ftFortran"?
With regards, Morten.

[MortenMacFly]

should we add another file type "ftFortran"?

...forget about that. I think just adding another FileFilter and modifying FileTypeOf() to include e.g. a new FileFilters::F_EXT should work I guess... Should I give it a try and propose a patch if that works?
With regards, Morten.

[mandrav]

should we add another file type "ftFortran"?

This sounds better. It will also solve the "manually check compile/link" when adding fortran files to the project.
I 'm on it...

[mandrav]

Can you try this patch and see if it solves the problem?

[attachment deleted by admin]

[MortenMacFly]

should we add another file type "ftFortran"?

This sounds better.

Ok... I guess it's really better to seperate that from C/C++ sources. Anyway: May I point to the following filey types known to be used in Fortran:
1.) *.f -> these are typically Fortran source files, most common
2.) *.f77 -> these are Fortran 77 source files that compile using any Fortran 77 compiler. This is often used if you mix Fortran77 and Fortran95 code together.
3.) *.f95 -> these are Fortran 95 source files that compile using any Fortran 95 compiler (also part of the GNU compiler suite, so it makes sense to support it). This is usually used if you use Fortran95 only (instead of *.f), but also if you mix Fortran77 and Fortran95 code together.
4.) *.cmn -> these usually hold the information about so-called "common blocks" which allows to group variables with a common sense - you could compare that with structs in C.
5.) *.inc -> these usually hold declarations for constants, variables and/or functions (external interfaces).

So if you want to make it "perfect" all these file types should be taken into consideration. Maybe not now (for a "quick fix") but in the future. Maybe the new compiler framework already takes this into consideration...

With regards, Morten.

[MortenMacFly]

Can you try this patch and see if it solves the problem?

...working on it... By the way: I also modified associations.cpp and const_bindings.cpp accordingly. I'll send a new patch if that works...

[MortenMacFly]

Ok, here it comes: Version 2 of the patch. The good news first: The breakpoint works now -> C::B focusses nicely in the editor. But there is also another issue which isn't so easy to solve: Look at the image I've attached what the debugger adds to the watches. Since the output is different from C/C++ there has some more work to be done...
With regards, Morten.
Edit: What I forgot to add: I've adjusted the patch to include the f95 extension, too. In addition I found a little unicode issue with the D file extension in associations.cpp... ;-)

[attachment deleted by admin]

[mandrav]

Regarding the watches tree, what's the output in the debugger's debug log?

[MortenMacFly]

Regarding the watches tree, what's the output in the debugger's debug log?

Here it is:

Code

> break main.f:4
Breakpoint 1 at 0x40131b: file main.f, line 4.
(gdb)
> run
Breakpoint 1, MAIN__ () at main.f:4
C:/DOKUME~1/morten/Desktop/fortran/main.f:4:81:beg:0x40131b
Current language:  auto; currently fortran
(gdb)
> info locals
Invalid F77 type code 3 in symbol table.
__g77_cilist_1 = (gdb)
> info args
No arguments.
(gdb)

[MortenMacFly]

...additional info: I've modified the application as follows to verify it's not an issue with the character datatype:

Code

      PROGRAM TINY

      INTEGER   IINT
      CHARACTER OCHAR*2

      IINT=2
      OCHAR='AA'

      WRITE(UNIT=*,FMT=*)'Hello world'
      WRITE(UNIT=*,FMT=995) IINT
      WRITE(UNIT=*,FMT=996) OCHAR

995   FORMAT(I2)
996   FORMAT(A2)

      END

But I get the same output on the watches window. Anyway, if I add the watches manually (right-click in the watches window and add watch) I see the values as witin the image attached. The debugger's output in that case is:

Code

> break main.f:9
Breakpoint 1 at 0x401310: file main.f, line 9.
(gdb)
> run
Breakpoint 1, MAIN__ () at main.f:9
C:/DOKUME~1/morten/Desktop/fortran/main.f:9:97:beg:0x401310
Current language:  auto; currently fortran
(gdb)
> info locals
Invalid F77 type code 3 in symbol table.
__g77_cilist_0 = (gdb)
> info args
No arguments.
(gdb)
> info locals
Invalid F77 type code 3 in symbol table.
__g77_cilist_0 = (gdb)
> info args
No arguments.
(gdb)
> whatis IINT
type = integer
(gdb)
> output IINT
2(gdb)
> info locals
Invalid F77 type code 3 in symbol table.
__g77_cilist_0 = (gdb)
> info args
No arguments.
(gdb)
> whatis IINT
type = integer
(gdb)
> output IINT
2(gdb)
> whatis OCHAR
type = char (2)
(gdb)
> output OCHAR
(65 'A', 65 'A')(gdb)

With regards, Morten.

Ps.: I've also googled around and found an issue with the GDB debugger and complex data types in fortran. This could be resolved by adding the compiler switch "-fno-emulate-complex" - which I tried. Unfortunately no success (which doesn't suprise me since we are not using the COMPLEX data type in this example).

[attachment deleted by admin]

[mandrav]

Regarding the watches tree, what's the output in the debugger's debug log?

Here it is:

Code

<snipped>
> info locals
Invalid F77 type code 3 in symbol table.
__g77_cilist_1 = (gdb)
</snipped>

Well, as you can see, the watch tree displays exactly what GDB sends it. I see no parsing (or other) bug here...

[MortenMacFly]

I see no parsing (or other) bug here...

...depends on the point of view. If you want to show everything the debugger sends in the watch window then it's ok, of course. But my understanding of the "watch window" was to see "watches" - thus variables and stuff and no error messages from the debugger. What I meant with parsing was that IMHO such info's should be filtered out. So it's not really a bug, ok... agreed on that. Sorry. ;-)
With regards, Morten.

[mandrav]

I see

[JoachimB]

I tried  :lol: the patch and it works!
Thank you both Mandrav and Morten for this quick fix

Now I couldn't figure out how to use the patch properly so I patched manually using the Codeblocks editor. Is there anyone that can hint where I can read about how to apply a patch in a little bit more automatic fashion. I did download patch.exe but could not work out how to use it. It was complaining about the format of the f77.patch file.

C:\Projects\CodeBlocks>patch -i f77.patch
can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/plugins/debuggergdb/debuggergdb.cpp
|==============================================================
|--- src/plugins/debuggergdb/debuggergdb.cpp    (revision 2438)
|+++ src/plugins/debuggergdb/debuggergdb.cpp    (working copy)
--------------------------
File to patch:

[MortenMacFly]

mandrav: Do you have plans to apply the (first/second) patch to SVN in the near future? Otherwise I'd put it to the patch tracker at BerliOS to make sure it's not getting lost.

JoachimB: What version of "patch" are you using? I'm using v2.5.9 the from the GNU Win32 tools which works (...usually ;-)). Did you try the "-u" option in addition? (The patches are usually in unified format). And of course you have to apply them in the right directory. So in your case there should really be a
"src/plugins/debuggergdb/debuggergdb.cpp" file/folder under "C:\Projects\CodeBlocks"...?!

With regards, Morten.

[mandrav]

mandrav: Do you have plans to apply the (first/second) patch to SVN in the near future?

Yes, today.

[joachim]

Hi Morten,

I downloaded the 2.5.9 and now after reading the manual I understand how it works with the -u and the strip -p option. Definitely more convienient then the manual way

Joachim(b)

[dmoore]

Hi guys: thought I'd append a message to an old thread since its the same topic. Can anyone tell me the current status of debugging fortran code in C::B using GDB? A colleague wants me to inspect her fortran code and I was hoping to avoid installing Visual Studio + Compaq Fortran etc.
I gave it a quick try but as described above, the editor still does not track the debugger's position in the code. I can live with this. By far the biggest problem is that the watch etc. don't work at all. Has anyone else managed to get a more successful gdb fortran session working in C::B?

EDIT: I forgot to add that I'm using the "new" Mingw G95 compiler (as opposed to G77 compiler) - so the problem is most likely the compiler... unfortunately the stuff i coded in fortran 90, so g77 isn't an option.

thanks
Damien

[dmoore]

I've added a trivial patch under pseudonym "cripes" (dmoore was taken already) to include .f95 and .f03 in the known filetypes. (shouldn't this stuff be in xml files, loaded and queried for known types as necessary?)

some annoying things when debugging fortran g95 with gdb (i don't know if this is also true of g77):
1. all global variables have a name prefix of something like global_variable_MP_ (i can't remember the exact prefix because i only have g95 installed on my work machine) so to watch a variable called "k" you actually need to watch global_variable_MP_k. This will make it almost impossible to watch expressions without the user typing the longhand name or some smart parsing.
2. It doesn't look like there is an easy way to watch the contents of arrays either (dereferencing with () or [] didn't seem to do the trick)
3. There's some weird jumping with debug step and next where the current line of code jumps to the start of the function header before proceeding to the next point in the code. That is, you have to press next twice to get to the next line (This may just be GDB/g95 weirdness that can't be fixed)
(4. not really a problem, but a gotcha) all variable names are transformed to lower case in the debugger (since fortran is case insensitive)

I don't know if any of this is patchable. For one, we would need a consistent way to identify that it is fortran code being debugged (I guess could be based on the file extension of the current source). I personally find Fortran a clumsy language that's best avoided, so unless I am required at work to spend more time debugging it in GDB, I won't know enough to come up with a suitable patch.