Re: debuggers - request for information

Arne Watnelie (arnew@ifi.uio.no) wrote:
: I'm writing a master thesis on the subject of debugging, and about an
: implementation of a debugger with a new view on how one may debug programs.
: (I'm a little abstract here, but the thesis and the program isn't written
: yet :-)...)
-snip-
: 1) Historical information about the birth of debugging.
: When did the need for debuggers arise? First debugger made?
No idea
: 2) Technical information about debugging.
: How is breakpoints etc. implemented?
Usually by replacing an instruction with some sort of trap instruction
that passes control to the debugger when executed. To go past it the debugger
then has to replace the original instruction, do one single step, reinstate
the breakpoint and then continue.
: How is the standard format of debugging code made by gcc and used by
: gdb?
I think gcc/gdb uses the native object format's debug tables - but I may be
wrong.
: 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.)
Take a look at heap debuggers and comms debuggers for some ideas.
: 4) Any nice window/point and click debuggers out there?
: (Which is something else than a traditional debugger splited into more
: than one window.)
Never found one.
: 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?
I would use extra code as far as possible. One reason is you can call
your own datastructure dump routines (some debuggers do allow you to call
user functions). Another is you can make the print intelegent by being
conditional on the situation (again some debuggers can execute conditions
on hitting a breakpoint). The execution does not stop after a print so
no need to keep hitting continue (some debuggers can continue after a break
[trace points] or better can do so some commands to print and then continue.)
The prints are in your code and can remain their under the control of
something like ifs or ifdefs. With a debugger you would have to keep
everything in a separate setup file (a maintenace problem, a different
language and very fiddly to use). The main use I make of debug tools (apart
from a heap debugger) is to get a stack trace on a crash [cursed are systems
which don't core dump (or equivalent) so you have to repeat the run with
a debugger when you get a crash]. Very occasionally single stepping in a
debugger can sort out a problem such as stack couruption or a compiler bug -
but it is slow and painful.
: 6) Why do so many people use debuggers only as the last resort, when all
: other alternatives have failed?
In addition to above answeres:
1: Compiling with full debug information is expensive (for a large program
                you may not have enough disk space to do it). If you have to
                rebuld a bit with debug turned on then you might as well rebuild it
                with some prints in (which is often easier to do too when using
                something like make).
2: Compiling with full debug information often dissables optimizations. This
                means you are not debuging the final system.
3: Debuggers can affect the behavior of the program, especially if you
                have an unitialized variable. This can make problems disapear under
                the debugger. (prints can have the same effect sometimes too!)
4: The debugger is another thing to learn - and if you are programing for
                multiple platforms that is one debugger for each. Prints in the
                code use the language you are programing in - nothing to learn.
5: Debuggers can be slow and unreliable.
6: Using debugers on programs that are run from scripts is a pain.
7: Prints can be there all the time and only need to look at the output
                after something has gone wrong.
8: It is too easy not to see the wood for the trees in a debugger.
--
Stephen Baynes baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton
United Kingdom
--

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