Re: debuggers - request for information

ok@cs.rmit.edu.au (Richard A. O'Keefe)
Thu, 20 Jul 1995 10:26:10 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: debuggers - request for information Zhiqing.Liu@att.com (Zhiqing Liu) (1995-07-17)
Re: debuggers - request for information vern@daffy.ee.lbl.gov (1995-07-17)
Re: debuggers - request for information kadhim@munge.cs.colorado.edu (1995-07-18)
Re: debuggers - request for information dmurphya@cix.compulink.co.uk (1995-07-18)
Re: debuggers - request for information baynes@ukpsshp1.serigate.philips.nl (1995-07-19)
Re: debuggers - request for information pardo@cs.washington.edu (1995-07-20)
Re: debuggers - request for information ok@cs.rmit.edu.au (1995-07-20)
Re: debuggers - request for information sriram@tcs.com (1995-07-20)
Re: debuggers - request for information R.Sosic@cit.gu.edu.au (1995-07-21)
Re: debuggers - request for information reid@HASKELL.SYSTEMSZ.CS.YALE.EDU (1995-07-22)
Re: debuggers - request for information bill@amber.ssd.hcsc.com (1995-07-25)
Re: debuggers - request for information pardo@cs.washington.edu (1995-07-26)
Re: debuggers - request for information boggs@osage.csc.ti.com (1995-07-27)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: ok@cs.rmit.edu.au (Richard A. O'Keefe)
Keywords: debug, design
Organization: Comp Sci, RMIT, Melbourne, Australia
References: 95-07-088
Date: Thu, 20 Jul 1995 10:26:10 GMT

Arne Watnelie <arnew@ifi.uio.no> writes:
>6) Why do so many people use debuggers only as the last resort, when all
> other alternatives have failed?


Because they are a seductive waste of time, compared with
  - static checkers (lint and friends, especially LC-lint)
  - assertions
  - better assertions


One of the most powerful debugging tools I ever used was a "path" checker.
The program was divided into modules,
each module had a number of entry points,
and I wrote a regular expression for each module,
where the "letters" in the r.e. were entry point names.


Here's the idea for C stdio, simplified a bit:


read = getc | fgetc | fgets | fscanf | fread ;
write = putc | fputc | fputs | fprintf | fwrite ;
file = fopen . (setbuf | setvbuf | null ) .
                              ( read+ | write+ | empty ) .
( fseek . ( read+ | write+ | empty ) )* . fclose ;


The path checker was actually implemented manually in my case; I transformed
the r.e.s to DFAs and added
static DFA_State $xxx$_transition[] = { ... };
if (ERROR == (state = $xxx$_transition[state]))
report error;
to each function $xxx$. This is like catching uninitialised variable
errors, but it can do a lot more. It would have been easy enough to
automate, and there has been work on doing that. (In particular, there
has been work on generating multi-thread synchronisation code from path
expressions.)


Another thing is that in the time that I've used UNIX, I've had to deal
with adb, sdb, cdb, dbx, and a couple of others that I'm still trying to
forget. sdb in particular had a nasty habit of crashing and spewing its
own guts all over my poor little 'core' file. Frankly, I am _tired_ of
learning new debuggers.


If a debugger won't let me add a new assertion to a program (ideally
letting me add any required new procedures for it), then there's no
point in me wasting any time learning it. The really important thing
is that the *machine* should do as much checking as possible: a good
debugger is one that _can_ show me everything but doesn't.


I think the best debugging environment I ever came across was Interlisp-D.
The "advice package" is precisely a means of dynamically adding assertions
to code without having to modify the sources.


--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.