Re: debuggers - request for information

I apologize in advance if some of the material in this article appears to
be commercial. The intent is to present information about a product I am
familiar with and which also has some characteristics relevant to this
discussion.


Arne Watnelie <arnew@ifi.uio.no> writes:
> 2) Technical information about debugging.
> How is breakpoints etc. implemented?


There are generally two approaches. One is to replace an instruction
of the debugged program (which I will refer to as the "debuggee") with
an instruction that causes the operating system to give control to the
debugger. This is, I believe, the approach used by gdb.


Another approach is to replace an instruction of the debuggee with a branch
to some region of code generated by the debugger. This code might, for
instance, rendezvous with the debugger without operating-system
intervention, or it might perform other tasks. In our debugger, this code
evaluates any conditions attached to the breakpoint so that the code runs
at full speed until the condition is satisfied.


> How is the standard format of debugging code made by gcc and used by
> gdb?


There is no "standard format". It varies widely, depending mostly on the
object-file format, of which there are many. One widely-used format on
Unix machines is COFF. It is an old format that is very limited in
capability. A newer format used on Unix machines is ELF/Dwarf (ELF
describes the format of the object code itself, Dwarf is the format of the
debug information within the ELF file). There are many other formats out
there, though.


> 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?


We think we have several innovations in our NightView debugger at Harris.


One innovation I mentioned above, of evaluating conditions attached to
breakpoints within the debuggee. Another is the ability to patch in
code at any point of execution to evaluate an expression or assignment.


A third innovation is what we call monitorpoints. A monitorpoint is a
patch to the program that evaluates a list of expressions and saves their
values. A separate window then displays these sampled values at
user-specified intervals. Monitorpoints allow the monitoring of
computations in a real-time program without interfering with its
performance.


A fourth innovation is the way that programs get started for debugging.
Most debuggers have some command that you must use to tell it which program
you want to debug. Ours merely starts up a Unix shell under the debugger
and debugs whatever you run in that shell. (There are methods of filtering
these so that you don't debug programs you don't want to.)


This allows our debugger to debug multiple programs at the same time, and
also allows the user to start and interact with his program in exactly the
same way, whether he is debugging or not. This is particular useful for
programs started by other programs or by complicated shell scripts.




One innovation that I think is sorely needed in the industry is a completely
new paradigm for debugging optimized code. Almost all debuggers still
have a line- or statement-oriented model of a program, but this does not
work very well in the face of aggressive optimizations.


For instance, many loop optimizations done by modern compilers can
completely rearrange the order of statements within a loop nest. They can
also replicate part or all of some statements.


Optimizations performed for super-scalar, vector, and parallel architectures
often end up intermixing the code for multiple statements.


In the face of all these optimizations, statement-oriented debugging is
painful and often nearly impossible. Operations like single-stepping
one statement or line at a time becomes tedious and pretty much useless,
because one statement may start before the previous statement is completed.


I don't have a solution for these problems. I think it is an area ripe for
research and experimentation.


> 4) Any nice window/point and click debuggers out there?


Most PC-based debuggers are windows-oriented. Many Unix-based debuggers
(including ours) have some sort of GUI interface. They vary widely in
quality and breadth of features.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com


These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.
[I recall having conditional breakpoints and patch on the fly in DDT 20
years ago. They were useful then, too. -John]
--

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