DBX under 4.2BSD
woods at hao.UUCP
woods at hao.UUCP
Mon Jan 30 16:46:11 AEST 1984
I have discovered that my initial evaluation of the new DBX debugger was a
bit harsh. Instead of saying "nothing works", I should say "the syntax is
strange, and some things don't work". I am performing some tests and when
I get done I will post a list of things that do and don't appear to work on
our version. I would appreciate comparisons from other sites. This is fairly
important to the FORTRAN hackers at our site (real C programmers use adb :-)
Some initial observations: Most of the trace commands do work, once you figure
out that a subroutine "suba" in file "suba.f" is traced by "trace suba.suba",
and that "trace suba" produces wierd results. Some of the stop commands do
work, but I haven't been able to get the "stop in routine if condition" to work
when "condition" was something simple like "a=0". One other oddity so far: like
every debugger originally written for C I've ever seen, it has problems with
FORTRAN common blocks. It also behaves radically differently if I initialize
values in common blocks with a data statement than if I initialize them with
an explicit assignment statement in the main program. In the first case, I
have code like:
common /test/f,i
data f,i/23.,5/
in my main program. I set a breakpoint in some subroutine containing this block.
When it hits the breakpoint, I do "whatis f", and I get an error message about
referencing a nil pointer. "whatis test" prints something like "&test=hex-addr"
Now, if I replace the data line with explicit assignments like
f=23.
i=5
and repeat the same, "whatis f" properly says "real f", but "whatis test"
causes the debugger to crash, again complaining about a nil pointer.
I will try and post more information tomorrow when I have more time.
Greg "FORTRAN hacker" Woods
--
{ucbvax!hplabs | allegra!nbires | decvax!kpno | harpo!seismo | ihnp4!kpno}
!hao!woods
More information about the Comp.unix
mailing list