SUMMARY: Better debugger for Fortran source?

From: Phil Antoine <antoine_at_RadOnc.Duke.EDU>
Date: Tue, 27 Aug 1996 12:51:48 -0400

> Subject: Better debugger for Fortran source?
> Date: Tue, 16 Jul 1996 09:48:59 -0400
> From: Phil Antoine <antoine_at_RadOnc.Duke.EDU>
>
>
> Fellow admins,
>
> I have a user who has requested a debugger that can cope with source
> level debugging (particularly include files) in FORTRAN. He's
> apparently been fighting with dbx and DECLADEBUG in unsuccessful
> attempts to debug the source in his include files.
>
> I don't have time or significant FORTRAN knowledge to help him figure
> out if he's doing it wrong or if its just not possible with those
> debuggers.
>
> So, are we doing it wrong or are there better tools for
> FORTRAN include source debugging?

Thanks to the following respondents for their input. We had
already tried most of these suggestions.

Mike Palmer <mpalmer_at_encore.com>
Francisco J Martin Ballesteros <frjomar_at_iies.es>
Tim Lucia <lucia_at_zko.dec.com>
Carlos A M dos Santos <ufpelrm_at_eu.ansp.br>
Winfried Huber <win_at_tukan.ffb.eunet.de>

The winner was Tim Lucia, with an acceptable reason as to why we're
having problems.

> On Digital UNIX, the symbol table representation does not allow for functions to
> span physical files. By including code from another file midway through a
> function, the symbol table rules are violated.
>
> The simpler answer is there is nothing we can do right now. What you can do is:
>
> 1. Write cleaner functions, using function calls instead of include. Compile
> with inlining turned on (see the f90 documentation)
>
> 2. Include code with #include directives and run it through cpp (The C-language
> preprocessor, see cc(1) for details) and then rename the .i file into a .f file
> and compile and debug that. This way, the compiler only sees the code as coming
> from one file.
>
> I don't think a complete example will make any difference, in this case. It is a
> well-known problem.


The key here is that our include files (*.if) were pseudo inline
bits of code as opposed to definitions and macros. We
had multiple (up to 6) includes in some functions, and some of the
include files used the include directive a few times.

We didn't use function calls because they killed performance in
tight loops. Looks like we will try Tim's option 2 or go through some
moderate rewrites to make this code source level debuggable.

Thanks for the help,

Phil Antoine (antoine_at_RadOnc.Duke.EDU)
Duke University Medical Center
Radiation Oncology Physics
Durham, North Carolina USA
http://www.RadOnc.Duke.EDU/~antoine
Received on Tue Aug 27 1996 - 19:19:38 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:47 NZDT