whm@arizona.UUCP (06/14/83)
I have developed a recent interest in debuggers for high-level
languages. I'm looking for references on source-level debuggers of
various sorts. The primary interest is in novel ideas in debuggers,
for instance, screen-oriented debuggers, and debuggers written in the
language they serve as debuggers for. Also of interest are debuggers
for unconventional languages. A secondary issue is that of inter-
active program development environments such as those associated
with Lisp, APL, and Mainsail.
I'm familiar with the various debuggers under UNIX (4.1bsd), I've
used some Lisp debuggers, and I've had excruciating amounts of
experience with "symbolic debuggers" of various types. I've heard
about a recent (last year) conference on High-Level Debugging and
understand that the proceedings are due out in a couple of months or
so. That's about all that I know of in the line of debuggers. As
for interactive development environments, I know of the ones
mentioned; are there others?
So, if you know of articles, books, etc., concerning debuggers or
interactive development environments, I'd like pointers to them.
If you have something in mind, please try to reply by about July 7
and I'll report my findings about a week or so after that.
Thanks,
Bill Mitchell
whm.arizona@rand-relay
{kpno,ihnp4,mcnc,utah-cs}!arizona!whmrb@ccird2.UUCP (Rex Ballard) (04/11/86)
There are a number of different "schools" in the compiler, debugger, enviroment debate. At one extreme is the group that would like to see a "generic" debugger that has no dependancies on the compiler (ala adb). Each "piece" should be independant. This way, they argue, you can use any editor, a variety of compilers, and a variety of debuggers. At the other end of the scale is the "environementalist" who would have you use a single integrated enviroment which was designed for that specific language. You would use the environments editor, compiler, debugger, and analysis tools. Many interpreted languages such as BASIC and FORTH function in much this way. What is really needed is both. A fully interactive enviroment allows unit testing of each module as it is written. It allows experimentation with library modules or built-ins to insure that no incorrect assumptions reguarding the calling procedures are made. many such environments allow examination of the lower level source as well. It also makes "ad hoc" tools and functionality very easy to implement. The "generic" environment on the other hand allows you to wring maximum performance out of the software. By using debug and profiler switches, using source and assembly level debuggers, the user is able to look at the "hot spots" and peculiar "assembly level bugs". The problem is, that certain constructs which are very easy for the compiler to do, are very difficult for the interpreter, and vice-versa. Try creating an interactive system capable of supporting full K&R C. Try supporting ALL of the libraries, even those for which you don't want developers hacking at source. Any "hybrid" language capable of supporting both environments requires new approaches in how software is implemented, organized, documented, and designed. Smaller modules are indicated, to allow modification of small functions without "rebuilding the world". Software must be organized to enable the developer to find existing functionality without "re-inventing the wheel". On-line documentation must be available so that the developer doesn't have do leave the enviroment to learn how to use a function. Designs must be more complete to allow the "bottom up" implementation of a "top down" design. Assemblers and linkers must be beefed up to allow the larger number of local and global variables required by such a system. They also must be equipped to handle long identifier names which will enable more self-descriptive names to be given. They must also create modules that can be used by the "interactive environment". This is a tall order, but worth considering.