Debugging fortran

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