Re: FORTRAN debugging

Re: FORTRAN debugging

[N8TM]

In a message dated 1/6/99 7:52:32 AM Pacific Standard Time,
Theodore.Todorov@cern.ch writes:

<< I tried gdb 4.17 (via ddd 3.1.2) on some code compiled
 with g77 (egcs 1.1b version), and couldn't
 print or display floating point variables >>
You didn't state your compiler options.  If you wish to see local variables in
gdb with -O, you must make them SAVE variables or use equivalent compiler
options.  As you saw, the rest is on the TODO list.

Re: FORTRAN debugging

[Theodore Todorov]

On Wed, 6 Jan 1999 N8TM@aol.com wrote:

> You didn't state your compiler options.  If you wish to see local variables in
> gdb with -O, you must make them SAVE variables or use equivalent compiler
> options.  As you saw, the rest is on the TODO list.
> 
I just used "g77 -g source.f", no optimisation.
I could get to integer local variables with some ddd commands, for
others I had to refer to variable "FOO" as "foo_" (ddd didn't do
it consistently), and REAL variables were interpreted as char[4],
so the only way to see their value was by taking their address and
using memory dump in float format. I did set the language to fortran
in ddd.

Re: FORTRAN debugging

[Dave Love]

>>>>> "TT" == Theodore Todorov <Theodore.Todorov@cern.ch> writes:

 TT> I could get to integer local variables with some ddd commands,
 TT> for others I had to refer to variable "FOO" as "foo_" (ddd didn't
 TT> do it consistently), and REAL variables were interpreted as
 TT> char[4], so the only way to see their value was by taking their
 TT> address and using memory dump in float format.

If you're not seeing names as decribed in the g77 manual, please
submit a bug report with details and code.  There's no reason I can
think of why a real datum should appear as char[4] and it generally
wouldn't.  But please try it with gdb.

Re: FORTRAN debugging

[Craig Burley]

>If you're not seeing names as decribed in the g77 manual, please
>submit a bug report with details and code.  There's no reason I can
>think of why a real datum should appear as char[4] and it generally
>wouldn't.  But please try it with gdb.

g77 sometimes "compiles" (implements via the back end) types as
the lower-level `char' type (i.e. an array thereof).  It might do
this on some systems for REAL and DOUBLE PRECISION (all the
floating-point types), but I've lost track.  It *certainly* does
this for things like `EQUIVALENCE (I,R)' and `COMMON I,R' -- cases
where an aggregate (EQUIVALENCE or COMMON area) consists of variables
of more than one class of type (e.g. integer and floating-point
types, or integer and character types).

        tq vm, (burley)

P.S. I've been in "email hell" for more than a week, and almost
certainly lost some messages.  But I've nearly got qmail fully
installed and configured locally (and just bought a few more
ORA books on the relevant topics to learn more), and should soon
be pulling email down from a new, more reliable ISP (finally!).

Re: FORTRAN debugging

[Toon Moene]

Craig Burley wrote:

> >If you're not seeing names as decribed in the g77 manual, please
> >submit a bug report with details and code.  There's no reason I can
> >think of why a real datum should appear as char[4] and it generally
> >wouldn't.  But please try it with gdb.

> g77 sometimes "compiles" (implements via the back end) types as
> the lower-level `char' type (i.e. an array thereof).  It might do
> this on some systems for REAL and DOUBLE PRECISION (all the
> floating-point types), but I've lost track.  It *certainly* does
> this for things like `EQUIVALENCE (I,R)' and `COMMON I,R' -- cases
> where an aggregate (EQUIVALENCE or COMMON area) consists of variables
> of more than one class of type (e.g. integer and floating-point
> types, or integer and character types).

Hmmm, I had not realized that some backends did this differently from
others ...  Might this be one of the reasons why debug output for COMMON
/ EQUIVALENCE still isn't supported ?

>         tq vm, (burley)

> P.S. I've been in "email hell" for more than a week, and almost
> certainly lost some messages.  But I've nearly got qmail fully
> installed and configured locally (and just bought a few more
> ORA books on the relevant topics to learn more), and should soon
> be pulling email down from a new, more reliable ISP (finally!).

I wish you lots of success !  I just switched from UUCP based mail to
SMTP based, and I still have the feeling I do not receive all mail sent
to me ...

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: FORTRAN debugging

[Craig Burley]

>> g77 sometimes "compiles" (implements via the back end) types as
>> the lower-level `char' type (i.e. an array thereof).  It might do
>> this on some systems for REAL and DOUBLE PRECISION (all the
>> floating-point types), but I've lost track.  It *certainly* does
>> this for things like `EQUIVALENCE (I,R)' and `COMMON I,R' -- cases
>> where an aggregate (EQUIVALENCE or COMMON area) consists of variables
>> of more than one class of type (e.g. integer and floating-point
>> types, or integer and character types).
>
>Hmmm, I had not realized that some backends did this differently from
>others ...  Might this be one of the reasons why debug output for COMMON
>/ EQUIVALENCE still isn't supported ?

Not exactly, though there's several issues with which those two are
intertwined.  So fixing the latter probably includes changing the
former.  Basically g77 currently tells the back end about aggregates
only as monolithic arrays of some type.  If that type can be `double',
`float', or `int', and still accommodate all the contained types,
g77 usually goes for that.  Otherwise, it picks `char'.  All the members
are accessed by pointer-offset games.

>I wish you lots of success !  I just switched from UUCP based mail to
>SMTP based, and I still have the feeling I do not receive all mail sent
>to me ...

Ah, well, I have been getting semi-bounce messages about uucp jobs
to you -- semi-bounce in that they say it's been three days since
mail has been pulled down, will try again later.  Maybe I've gotten
bounce messages as well.  I didn't give them much thought because
you clearly were reading email.  I think these occur primarily on
bounces from <fortran@gnu.org>, of which I'm the current owner.  Let
me know if you want me to forward the next one or two of these that
I get, if any.

        tq vm, (burley)

Re: FORTRAN debugging

[Toon Moene]

Craig,:

> Not exactly, though there's several issues with which those two are
> intertwined.  So fixing the latter probably includes changing the
> former.  Basically g77 currently tells the back end about aggregates
> only as monolithic arrays of some type.  If that type can be `double',
> `float', or `int', and still accommodate all the contained types,
> g77 usually goes for that.  Otherwise, it picks `char'.  All the members
> are accessed by pointer-offset games.

OK, so it's the *front-end* that's making the decision here (so the
behaviour should be the same on all targets).  At least to me that
suggests that a particular EQUIVALENCE or COMMON can or cannot be
"annotated" with debugging information regardless of the target system -
assuming that it works if the aggregate consists of equal types (whether
it's independent of the target debug format is not clear to me yet, but
I would be surprised if it were dependent on it).

[ About e-mail ]

> >I wish you lots of success !  I just switched from UUCP based mail to
> >SMTP based, and I still have the feeling I do not receive all mail sent
> >to me ...
> 
> Ah, well, I have been getting semi-bounce messages about uucp jobs
> to you -- semi-bounce in that they say it's been three days since
> mail has been pulled down, will try again later.  Maybe I've gotten
> bounce messages as well.

It might be the system(s) you reading and replying to mail on are still
thinking mail to moene.indiv.nluug.nl has to be delivered to uucp.nl.net
(that was the address used to gather the UUCP mail for NLnet connected
systems).

However, the correct Domain Name Service entry for my domain
(moene.indiv.nluug.nl) is:

[toon@moene toon]$ nslookup
Default Server:  ns.NL.net
Address:  193.78.240.1

> set q=mx
> moene.indiv.nluug.nl
Server:  ns.NL.net
Address:  193.78.240.1

moene.indiv.nluug.nl    preference = 50, mail exchanger =
mail.moene.indiv.nluug.nl
moene.indiv.nluug.nl    preference = 100, mail exchanger = etrn.NL.net
moene.indiv.nluug.nl    preference = 150, mail exchanger = smtp.NL.net

[ etc. ]

This might also explain the egcs-bugs/egcs-patches hiccups ....

Hope this helps.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: FORTRAN debugging

[Craig Burley]

>Craig,:
>
>> Not exactly, though there's several issues with which those two are
>> intertwined.  So fixing the latter probably includes changing the
>> former.  Basically g77 currently tells the back end about aggregates
>> only as monolithic arrays of some type.  If that type can be `double',
>> `float', or `int', and still accommodate all the contained types,
>> g77 usually goes for that.  Otherwise, it picks `char'.  All the members
>> are accessed by pointer-offset games.
>
>OK, so it's the *front-end* that's making the decision here (so the
>behaviour should be the same on all targets).  At least to me that
>suggests that a particular EQUIVALENCE or COMMON can or cannot be
>"annotated" with debugging information regardless of the target system -
>assuming that it works if the aggregate consists of equal types (whether
>it's independent of the target debug format is not clear to me yet, but
>I would be surprised if it were dependent on it).

The debugging-info problem is mostly separate from this, but changing
this to use the back-end record (`struct' in C) facility is probably
one of the very first things to get working as part of fixing the
debug-info problem.

The front-end's decision-making process, regarding the underlying
type it chooses for an aggregate, might be sensitive enough to
the underlying types of the Fortran types it knows about to cause it to
*not* have the same behavior on all targets.  I wouldn't assume
it'd make the same choices without investigating carefully first.

        tq vm, (burley)

Re: FORTRAN debugging

[Dave Love]

>>>>> "Tim" == Tim Prince <N8TM@aol.com> writes:

 Tim> If you wish to see local variables in gdb with -O, you must make
 Tim> them SAVE variables or use equivalent compiler options.

Surely not in general, but variables may be optimized away silently,
of course.  (It would be nice if such info could be recorded, as other
systems manage.)

FORTRAN debugging

[Theodore Todorov]

Hello,

Is there a combination of g77 and gdb versions that allows
reasonable debugging of FORTRAN source?
I tried gdb 4.17 (via ddd 3.1.2) on some code compiled
with g77 (egcs 1.1b version), and couldn't
print or display floating point variables, while arrays
in common blocks were definitely unreachable.

After digging through the documentation a bit I found
that gdb does not support FORTRAN, and that g77
has no debugging support yet for common blocks.

Is this really the situation?

                 Thank you in advance,
                            Teddy Todorov (t.todorov@cern.ch)

P.S. Please reply to my mail address above, since I am not
subscribed to the egcs list - the list archieves on the web
are so convinient!

Re: FORTRAN debugging

[Dave Love]

>>>>> "TT" == Theodore Todorov <Theodore.Todorov@cern.ch> writes:

 TT> After digging through the documentation a bit I found
 TT> that gdb does not support FORTRAN, 

It supports Fortran, but with the conventions of a different compiler.
Having failed to get on whether we'd be allowed to change it, nothing
got done.  I'm not sure whether or not you can still crash gdb with
g77 o/p, but you could previously.

 TT> and that g77 has no debugging support yet for common blocks.

See the manual.

 TT> Is this really the situation?

The situation should be as described in the g77 manual.  If not,
report a bug, please.

[Yes, this is an unsatisfactory situation...]

Re: FORTRAN debugging

[Andy Vaught]

Craig Burley (burley@gnu.org) writes:

>The debugging-info problem is mostly separate from this, but changing
>this to use the back-end record (`struct' in C) facility is probably
>one of the very first things to get working as part of fixing the
>debug-info problem.
>
>The front-end's decision-making process, regarding the underlying
>type it chooses for an aggregate, might be sensitive enough to
>the underlying types of the Fortran types it knows about to cause it to
>*not* have the same behavior on all targets.  I wouldn't assume
>it'd make the same choices without investigating carefully first.


  I made a patch available to the g77 folks a while back that appears to
fix the common debug problem in the present incarnation of g77-- anyone
here is welcome to it as well.  I've been using the resulting g77 for a
while with no apparent problems. 

  In both stabs and in the resulting assembly code, variables inside
common blocks appear to be vanilla static variables, just as if they were
SAVEd.  What happens is that the compiler generates assembly code that
indeed has the address of a common variable as a base of the common block
plus a constant offset.  Since two constants add to a constant, the
assembler generates an instruction that references a constant address. The
addition of the two constants is done later by the linker.  Under my
patch, stabs associated with variables are emitted in the same manner by
g77, and fixed up in the same manner by the linker so that in the end,
common variables have constant addresses. 

  Craig is clearly grappling with a long term "clean" solution, but it is
not clear that the generated code (or stabs) would be any different with a
"struct" solution to the problem.  One reason for doing this would be so
that stabs marking the common variables could be output in order that the
gdb 'common' command would work (no real loss IMHO). 

      Andy

-----------------                        XOLD(K,IC,I)=
Andy Vaught               ....        DO ITERS=1, 10  XOLD(K,IC,I)
andy@maxwell.la.asu.edu   |  |   /CALLMSOLVE(A,B,X,I,ITERS,TOL)+(RANNYU(0)
Arizona State University  ======|WRITE(6,'(I5,2X,F12.6)')ITERS,TOL -HALF)
Tempe, Arizona USA        OOOOOO \ENDDORETURN PARAMETER(ZERO=1.D0)*TENTH*DELTA