Re: debuggers - request for information

  > In the work with my master thesis, I have searched internet and libraries
  > for debugging related information, with little luck. Maybe I'm the only one
  > who don't manage to write correct programs? :-)
  >
  > Any pointers to related information, either in books or on the internet,
  > would be very, very welcome.


There is quite a bit of work on debugging available.


  > Some suggestions about what type of information am I looking for:
  > 1) Historical information about the birth of debugging.
  > When did the need for debuggers arise? First debugger made?


Although, the following references aren't the first debuggers, they are
some of the earlier efforts in high level source debugging:


@InProceedings{VAXDEBUG,
    author = "Bert Beander",
    title = "{VAX} {DEBUG}: An Interactive, Symbolic, Multilingual
Debugger",
    booktitle = "Proceedings of the {ACM} {SIGSOFT}/{SIGPLAN} Software
Engineering Symposium on High-Level Debugging",
    year = 1983,
    organization = "{ACM}",
    month = aug
}


In fact, you can look at a lot of other articles in the above proceedings.


@Article{JohnsonDesign,
    author = "Mark Scott Johnson",
    title = "Translator Design to Support Run-time Debugging",
    journal = SP+E,
    year = 1979,
    volume = 9,
    pages = "1035--1041"
}
@TechReport{JohnsonThesis,
    author = "Mark Scott Johnson",
    title = "The Design and Implementation of a Run-Time Analysis and
Interactive Debugging Environment",
    institution = "University of British Columbia",
    year = 1978,
    number = "78-6",
    month = aug,
    note = "Ph.D. Thesis"
}


The following glossary provides some interesting information as well:


@Article{Glossary,
    author = "Mark Scott Johnson",
    title = "A Software Debugging Glossary",
    journal = Notices,
    year = 1982,
    volume = 17,
    number = 2,
    pages = 53,
    month = feb
}


  > 2) Technical information about debugging.
  > How is breakpoints etc. implemented?


Some work in this area can be found in:


@InProceedings{inline,
    author = "David Keppel",
    title = "A Portable Interface for On-The-Fly Instruction Space
Modification",
    pages = "86--95",
    booktitle = "Proceedings of the Fourth International Conference on
Architectural Support for Programming Languages and
Operating Systems",
    year = 1991,
    organization = "{ACM}",
    month = apr
}


There was also an article, called something like "Fast Breakpoints" that
I believe was written by Kessel and appeared in SIGPLAN's PLDI proceedings
from I believe '92 or '93 (I'm sorry I don't have the exact reference
handy).


  > How is the standard format of debugging code made by gcc and used by
  > gdb?
  > (For me this will be background information. In my implementation, I
  > will probably use gdb to do the dirty, low level job for me, and spend
  > my time on more high level functions.)


There is an unpublished document about the internals of the GNU debugger.
Unfortunately, I can't remember exactly where I got it:


@Unpublished{gdb,
    author = "Robert Pizzi",
    title = "{GNU} Debugger Internal Architecture",
    note = "Department of {A}pplied {S}cience, {U}niversity of
{C}alifornia at {D}avis, {L}awrence {L}ivermore {N}ational
{L}aboratory.",
    year = 1993,
    month = dec
}


There is also an article about the evolution of dbx:


@InProceedings{Dbx,
    author = "Mark A. Linton",
    title = "The Evolution of {Dbx}",
    pages = "211--220",
    booktitle = "Proceedings of the {USENIX} Summer Conference",
    year = 1990,
    organization = "{USENIX}",
    month = jun,
    note = "In Anaheim, California"
}


  > 3) Have anybody made any creative, new debuggers who breaks the tradition
  > of using breakpoints, stepping etc.? Implementing new, untraditional
  > approaches to the debugging task?
  > (Like when people suddenly made cursor-oriented editors instead of
  > line-oriented/command-oriented editors.)


There are approaches that try to automate the process of debugging using
techniques like program slicing:


@phdthesis{AgrawalHir1991a,
  author ="Agrawal, Hiralal",
  title ="Towards Automatic Debugging of Computer Programs",
  school ="Purdue University, SERC",
  month ="August",
  year ="1991",
  scope ="debug",
  documentURL ="ftp://ftp.cs.purdue.edu/pub/serc/tech-reports/By-Project/debugger/TR103P.PS.Z"
}


A lot of more creative approaches to debugging can be found in the area
of debugging optimized code. The people at Convex had a paper in PLDI
a few years ago about their debugger for optimized code that did
some interesting things.


There is one article that does exactly what you are talking about. They
extended GDB to debug C programs with more interesting kinds of
commands:


@InProceedings{DUEL,
    author = "Michael Golan and David R. Hanson",
    title = "{DUEL} -- A Very High-Level Debugging Language",
    booktitle = "Proceedings of the {USENIX} Winter Conference",
    year = 1993,
    organization = "{USENIX}",
    month = jan,
    note = "In San Diego, California"
}


  > 4) Any nice window/point and click debuggers out there?
  > (Which is something else than a traditional debugger splited into more
  > than one window.)


There are a number of commercial debuggers that provide graphical user
interfaces to debugging.


  > 5) Debuggers vs adding extra code in the program manually to track down and
  > correct bugs. What may you do with extra code that a debugger can't
  > offer, and what may a debugger offer that extra code can't help you
  > with?


If your debugger doesn't have a very powerful command language, it is
sometimes easier to program a way to extract the information you want
rather than trying to use primitive debugging commands. Using powerful
debugging commands can degrade application performance tremendously making
it necessary to use extra code instead of debugging. Data breakpoints
are a good example of this. Using extra code does require you to
recompile the program every time, though, which is perhaps the biggest
nuisance.


  > 6) Why do so many people use debuggers only as the last resort, when all
  > other alternatives have failed?


I disagree strongly with this statement. I use debuggers all the time and
I certainly don't believe that I am in the minority. Having debuggers
has almost become a requirement for companies wanting to release new
compilers.


  > Thanks for reading and any help you may offer!


The above is only a small glimpse of the material available on debugging.
There is a lot more!


Basim Kadhim kadhim@cs.colorado.edu
University of Colorado, Boulder
--

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