🚀 go-pugleaf

MATOVICM@QUCDN.QueensU.CA () writes:
: I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
: programs. Examining arrays is pain in a neck unless you deal with the
: size a(3,3) or similar. Is there any way to say e.g.
:   print a from 155 to 175 (and possibly to specify the increment).
: Or, is there any other UNIX (public domain) debugger that can handle
: arrays frinedly?

your dbx should let you do
&a(155)/20f
to print the 20 elements of a in floating point format starting at element
155. It's not the most friendly way but it is better than listing the whole
thing.

In article <1993Jan22.135940.9828@msdrl.com> ball@msdrl.com (Richard Ball) writes:
>MATOVICM@QUCDN.QueensU.CA () writes:
>: I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
>: programs. Examining arrays is pain in a neck unless you deal with the
>: size a(3,3) or similar. Is there any way to say e.g.
>:   print a from 155 to 175 (and possibly to specify the increment).
>: Or, is there any other UNIX (public domain) debugger that can handle
>: arrays frinedly?
>
>your dbx should let you do
>&a(155)/20f
>to print the 20 elements of a in floating point format starting at element
>155. It's not the most friendly way but it is better than listing the whole
>thing.

Yeah, but sadly this only allows contiguously stored array elements to
be displayed.  It would be nice to be able to display _logically_ contiguous
elements, even when they are not stored contiguously i.e. "print A(1,7-15)",
or some such syntax.

More generally speaking, dbx is a relentless headache when debugging
fortran code.  In its incarnation on sun4's, locating trapped floating point
exceptions requires laborious procedures that work haphazardly, at best.
Often operation which might be expected to generate floating point
exceptions (logs of negative numbers, for example) generate segmentation
violations instead, and dbx appears to halt in a part of the code unrelated
to where the problem occurred.

Case sensitivity is another hassle.  dbx may be set to be case insensitive
if required, but for reasons that defy comprehension this affects the
way dbx understands filenames as well, so that after a "dbxenv case
insensitive" it is impossible (for example) to change to a directory
with a partially capitalized name.

I'm no expert on the subject, but I suspect that the problem has to do
with the fact that dbx was not designed as a fortran debugger, and that
it was "fortranized" by a series of awkward patches.  Unfortunately, I
am aware of no alternative available for Unix workstations.  I feel that
this is a serious limitation in the developement environment offered by
vendors of fortran packages for unix.

I can't say I miss working on a VAX, but I sure do miss the VAX fortran
environment.

Carlo

-----------------------------------------------------------------------------
Carlo Graziani           |   Warning:  some of the above may not be a fully  |
Dept. of Physics         |   correct representation of profound cosmic truth.|
University of Chicago    |                                                   |
                         |  "It's fun to have fun, but you have to know how!"|
carlo@nu.uchicago.edu    |                           -The Cat in the Hat     |
-----------------------------------------------------------------------------

MATOVICM@QUCDN.QueensU.CA () writes:
> I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
> programs. Examining arrays is pain in a neck unless you deal with the
> size a(3,3) or similar. Is there any way to say e.g.
>   print a from 155 to 175 (and possibly to specify the increment).
> Or, is there any other UNIX (public domain) debugger that can handle
> arrays frinedly?

I can't help you for SGI equipment, but the dbx for SPARCstations
provided in SPARCworks 2.0.1 appears to do exactly what you want.

The manual *Debugging a Program* states

Syntax for FORTRAN Array Slicing and Striding

     For each dimension of an array, the full syntax to the
     print command to slice the array is:

	 (debugger) print arr (exp1:exp2:exp3)

	 where:

	     exp1 = start_of_slice
	     exp2 = end_of_slice
	     exp3 = length_of_stride
		    (the number of elements skipped is exp3 - 1)

    For an n-dimensional slice, separate the definition of each
    slice with a comma:

	(debugger) print arr (exp1:exp2:exp3, exp1:exp2:exp3,...)

The manual goes on to explain how the elements are laid out in storage,
and convenient shorthand notations.

					Yours truly,
					Robert Corbett

jfu2@kimbark.uchicago.edu (Carlo Graziani) writes:

>In article <1993Jan22.135940.9828@msdrl.com> ball@msdrl.com (Richard Ball) writes:
>>MATOVICM@QUCDN.QueensU.CA () writes:
>>: I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
>>: programs. Examining arrays is pain in a neck unless you deal with the
>>: size a(3,3) or similar. Is there any way to say e.g.
>>:   print a from 155 to 175 (and possibly to specify the increment).
>>: Or, is there any other UNIX (public domain) debugger that can handle
>>: arrays frinedly?
>>
>>your dbx should let you do
>>&a(155)/20f
>>to print the 20 elements of a in floating point format starting at element
>>155. It's not the most friendly way but it is better than listing the whole
>>thing.

>Yeah, but sadly this only allows contiguously stored array elements to
>be displayed.  It would be nice to be able to display _logically_ contiguous
>elements, even when they are not stored contiguously i.e. "print A(1,7-15)",
>or some such syntax.

As if by magic, something called "Duel" has been posted in alt.sources.  I
claims to be a high-level debugging language which does exactly what you
require.  The caveat is that is will currently only work with gdb (Gnu 
debugger?), but can be implemented with dbx, etc.

Here's the intro from the post...
--
Dave!

-----------------------------------------------------------------------------
DUEL -  A high level language for debugging C programs.
-----------------------------------------------------------------------------
Duel is a special purpose language designed for concise state 
exploration of debugged C programs under existing debuggers.
It allows you to explore your program's state better than either 
the debugger's commands, a C interpreter, or print statements
added to your programs. The debugger is extended with the new 
'dl' command for Duel expressions:
     gdb> dl x[1..10] >? 5
     x[3] = 14
     x[8] = 6
prints the array elements x[1] to x[10] that are greater than 5. 
The output includes the values 14 and 6, as well as their 
symbolic representation "x[3]" and "x[8]".
 
The output includes the values 14 and 6, as well as their 
symbolic representation "x[3]" and "x[8]".
Duel is debugger-independent, but the current distribution interface only
with gdb. You will need the source for gdb-4.6, or 4.7. Duel is public 
domain code. Do whatever you like with it - add it to commercial debuggers,

to dbx/sdb or even make it part of the GNU project. 
No part of this distribution contains any copyright or derived code,
(i.e. no GPL code, either). Free and public domain code need no disclaimer,

which is obvious to anyone in the software business.
Even if you don't normally use debuggers, but you are programming in C,
give
Duel a try! The man page & help even include summary of useful gdb
commands.
Duel is available for anonymous ftp from ftp.cs.princeton.edu, in 
/duel/duel.tar.Z. "tar.Z" format means you should use the command
 "zcat duel.tar.Z | tar xf -" to unpack the files.
The Usenix Jan/93 paper about Duel is also available as tech report 399,
in /reports/1992/399.ps.Z on ftp.cs.princeton.edu
DUEL is "Debugging U (might) Even Like" or "Don't Use this Exotic Language"
you should judge which is better!

Thanks a lot to all the people that bothered to respond. At least I know now
that my headache is real, because the responses seem to point somewhere in the
future (if FORTRAN lives long to see it?), with the exception of the dbx fea-
ture offered on the SPARC, but, then, I work on SGI for the time being.

I think I could have the solution in principle, but I couldn't make it work.
Here is the idea:
    DBX allows interactive function (and in FORTRAN, subroutine) calls from
within debugger, if this function/subroutine is linked with the program. This
way, I managed to incorporate a routine that dumps all my data in the output
files whenever a want it. I simply enter
       ccall mywrite
Than using other (simple) program I examine that database. This whole thing
would work MUCH better if I were able to pass the arguments to the subroutine
or function call. So far, I've been trying... The problem is that dbx requests
C calling conventions even for the FORTRAN debuging, and I couldn't match these
conventions so far. I've tried to reverse the order of arguments, to compile
the C routine (just the one to print data) using mkf2c interface, than assemb-
ler, and all I managed is to drive my frustration up. Anybody out there that
could add to this?

Darko Matovic