Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: C++ debugging?
Message-ID: <10053@ulysses.homer.nj.att.com>
Date: 12 Feb 88 04:45:30 GMT
References: <41938@ti-csl.CSNET>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector (Jerry Schwarz)
Organization: AT&T Bell Labs, Murray Hill
Lines: 43

In article <41938@ti-csl.CSNET> ramey@ti-csl.UUCP (Joe Ramey) writes:
>(I'm sure this question has been asked before, so perhaps someone with
>a summary could forward it to me.)  How well does dbx debug C++ code?

The flip answer is that dbx doesn't debug code, I do.  But seriously,
a lot depends on the working environment. Given the environment I
work in I find dbx a very usable tool.

My environment consists of the latest version of C++ (not yet
available but "coming soon") using  4.3BSD on a VAX with an AT&T
MTG630 bitmapped terminal and running ksh.  (The importance of the
latter two considerations will become clear below.)

In this environment, dbx works with the original C++ source files.
That is, it reports lines in terms of the original files, you can set
breakpoints in terms of the original files, and when it prints source
it prints source from the original files. The major problem is that
the the names of variables, functions, and structure members are the
"mangled" versions.  That is, the names present in the intermediate C
files, not those you are looking at in the C++ source files. These
names are long, not always easy to figure out and would be a servere
problem if it were not for the terminal and shell environments.

First, the terminal helps a lot because it allows me to copy what
appears on the screen.  For example, when I want to set a breakpoint
on some overloaded function I go to another window and do an "nmg"
(nm piped through grep) of the name.  This will give the symbols
containing the name.  With a little practice it is easy to figure out
which one I want.  I can then pull the symbol off the screen with the
mouse and send it to the dbx process. Thus I never have to type it.
It is also usually possible to induce dbx to print variable names
(e.g. dump) or structure member names (e.g. printing the whole
structure).

Second, ksh is important because if provides a history mechanism and
inline editing.  I have a ksh script that sits as a filter in front
of dbx, and allows me to use these ksh features while interacting
with dbx.  The history is preserved across invocations of dbx.  Once
I have used a name in debugging I can usually get it back quickly by
doing a search in the history.

Jerry Schwarz
Bell Labs