Debugging executables generated by g95 on Linux

Has anyone tried to debug such executables with gdb or ddd?

Thanks in advance,

--
FCC.

===
Murmur not, question not,  but make the most of it!
-Nathaniel Hawthorne.

FCC <fcc509@netscape.net> writes:

| Has anyone tried to debug such executables with gdb or ddd?

yes, it is not yet completely trivial. I guess some more magic needs
to be added to either gdb or g95 before it can be used by mortals... I
think I saw it on the «coming soon» list of g95. maybe andy vaught can
comment on this?


a few things I manage
to do is the following:

I can stop in the beginning of the main program

break MAIN_
r

set a breakpoint in the beginning of a subroutine called dypgrin and
continue to it:

break dypgrin_
c

looks like Fortran symbols mostly have a _ appended, and will be
pointers.  this is also true for subroutines and functions.
to see a list of all functions ending with an underscore

info functions _$

display a list of all locally defined symbols in dypgrin_

info scope dypgrin_

list all variables, except those in the local scope
info variables

print the value of a fortran variable called DEPMIN in this scope
(c type dereferencing)

p *depmin

and so on... if you manage to find the pointer to one of your fortran
arrays, gdb allows you to print out a range of those using the @
operator, e.g. if your array is pointed to by "data" you can say

p *data@10

to see the first 10 items.

Helge

Helge Avlesen <avle@ii.uib.no> writes:

| FCC <fcc509@netscape.net> writes:
|
| | Has anyone tried to debug such executables with gdb or ddd?

one more thing, you need a fairly recent gdb version for it to work at
all - I have GNU gdb 6.2.1

if anyone have more useful gdb tricks for g95, please share...

Helge

In article <co74kv$6vk$1@defalla.upc.es>, FCC  <fcc509@netscape.net> wrote:

>Has anyone tried to debug such executables with gdb or ddd?

We looked into extending gdb to do all of Fortran95, and it turned out
it was cheaper to write our own debugger from scratch. The issue is
that it's complicated to support the 5 billion platforms that gdb
supports, and supporting only one ({i386,amd64}-linux-elf) is far
easier.

So, I wouldn't hold my breath for gdb working well with gfortran until
someone plonks down real $$ to do the job.

-- greg
speaking for myself, not PathScale

"Greg Lindahl" wrote >

> So, I wouldn't hold my breath for gdb working well with gfortran until
> someone plonks down real $$ to do the job.

What about just finding the line number where a crash occurs?  That's all I
use gdb for anyway.

> What about just finding the line number where a crash occurs?  That's all I
> use gdb for anyway.

that seems to work (with gdb 6.1 in my case, but later might be
better)

/g95> cat mytest.f90
REAL, ALLOCATABLE, DIMENSION(:) :: a
I=1
ALLOCATE(a(1))
a(I)=1
I=-199900
a(I)=-199900
END
/g95> g95 -g mytest.f90
/g95> gdb a.out
GNU gdb 6.1 [...](gdb) run
Starting program: g95/a.out

Program received signal SIGSEGV, Segmentation fault.
0x08049352 in MAIN_ () at mytest.f90:6
6       a(I)=-199900

I'm not sure that it is always working 100% right, but I regularly use
it on 300 kLOC code quite successfully (where other
compilers/debuggers fail). But e.g. this is a bit annoying:
(gdb) print I
No symbol "I" in current context.
(gdb) print i
$1 = -199900
I guess this will be fixed one day...

Two things I found useful:
-) typing 'where' to get a stack trace after a segfault
-) the syntax to set breakpoints on module procedures:
break modulename_MP_procname_

Joost

"Joost VandeVondele"  wrote>

> typing 'where' to get a stack trace after a segfault

If you use cygwin, the cygwin stackdump provides similar information.  You
need an awk script to read it, available in the cygwin mailing list
archives. I suppose this will continue to work after gfortran replaces g77.