woods@hao.UUCP (Greg Woods) (01/20/84)
Well, the highly-touted new debugger is a piece of junk, at least the
vanilla-flavored version we have on our 4.2 VAX 11/750 system. The "trace"
and "stop" commands do not work, or at least, not at the place you specify.
Has anyone else been successful using dbx(1) on f77(1) programs? Does
it work on C programs? Has anyone else noticed the same problem we have?
Are there bug fixes we haven't heard about yet? I can't wait until our
FORTRAN hackers find out that the debugger doesn't work. I forsee the
UNIX<-->VMS debate heating up again (shudder).
GREG
--
{ucbvax!hplabs | allegra!nbires | decvax!kpno | harpo!seismo | ihnp4!kpno}
!hao!woodsgwyn%brl-vld@sri-unix.UUCP (01/21/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> To make matters even worse, "sdb" seems to have gone away. I am again resorting to "adb" on those rare occasions when I have use for a debugger.
pag@hao.UUCP (Peter Gross) (01/23/84)
sdb can be found in 4.2bsd under the directory /usr/src/old/sdb. --peter
woods@hao.UUCP (01/30/84)
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