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