This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: gdb and Fortran90 arrays
- From: Parker James E Contr AFRL/HEDR <James dot Parker dot ctr at brooks dot af dot mil>
- To: "'Bloch, Jack'" <jack dot bloch at siemens dot com>
- Cc: "'gdb at sources dot redhat dot com'" <gdb at sources dot redhat dot com>
- Date: Fri, 1 Jul 2005 16:31:40 -0500
- Subject: RE: gdb and Fortran90 arrays
Jack,
How do I use the offset and base information to determine what section of
memory to look at?
Jim Parker
Research Physicist
General Dynamics
8355 Hawks Road
Building 1168
Brooks City-Base
San Antonio TX 78235
210 536 4083
-----Original Message-----
From: Bloch, Jack [mailto:jack.bloch@siemens.com]
Sent: Friday, July 01, 2005 4:11 PM
To: Parker James E Contr AFRL/HEDR
Subject: RE: gdb and Fortran90 arrays
Use the x command to examine the memory
-----Original Message-----
From: gdb-owner@sources.redhat.com [mailto:gdb-owner@sources.redhat.com] On
Behalf Of Parker James E Contr AFRL/HEDR
Sent: Friday, July 01, 2005 5:09 PM
To: 'gdb@sources.redhat.com'
Subject: gdb and Fortran90 arrays
Hello,
I was wondering if anyone could help me decipher the output from gdb when
debugging Fortran90 code. Since gdb doesn't currently support Fortran90, it
defaults to a language format called "minimal", which is fine for most uses,
but for arrays the output is cryptic for me.
Example
define an array
real(KIND(1.0D0)), dimension(6)::x
If I wanted to examine x(2), I normally (fortran 77) would use
(gdb) p x(2)
But under the minimal language setting, gdb interprets parenthesis as a
function call--that of course doesn't exist--and therefore gdb complains
with an error. I tried using [ ] to replace the parentheses, but gdb
correctly replies that operator [] is undefined.
The best result I have is at a gdb prompt type
(gdb) p x
And you get a list that contains an offset, ecode, base and info. Can
anyone tell me what these things are? Ecode seems to represent the size of
each element in the array, but that's just a guess. The rest is some sort
of memory pointer, but I can't decipher it.
Jim Parker