"sdb" vs. "dbx" (was Re: I HATE DBX! I HATE DBX!)

[Guy Harris]

> I know dbx seems to take longer to start up, and apparently its use with
> large scale software projects makes it prohibitive,

Several companies have modified "dbx" to speed up its startup; Tolerant
Systems and Celerity have already spoken up, and Sun has also done so (I
think all three of us have modified the linker to throw out duplicate
definitions from header files, and are thinking about or have already
modified it to read in symbols only when needed).

> I still like it a LOT more than sdb.  The big plus is that it handles
> structures correctly, but there are others.

To be fair, you're probably working with the 4BSD "sdb", which is later than
the System III "sdb" but earlier than the System V "sdb".  The "sdb"s of
System III and 4BSD vintage are, to put it charitably, crap.  (I know - I
spent a lot of time fixing bugs and porting it to a 68000-based machine with
16-bit "int"s and 32-bit pointers.)  The System V version, I believe,
handles structures correctly; the problem was that the symbol table format
in S3/4BSD didn't support the new structure member rules introduced in
System III, but the Common Object File Format in System V does.

However, I do agree that it still has many advantages over "sdb".  It has a
command syntax which is much closer to being unambiguous; the "sdb" syntax
is, to put it bluntly, a hack ("u" by itself prints the variable "u", unless
they've added a "u" command since then, while "b" by itself sets a
breakpoint).  "dbx" still has ambiguities of a sort; "stop at 5" means "stop
when the process reaches line 5 of the current source file", "stop at" means
"stop when the variable name 'at' (if there is such a variable) changes its
value", and "stop 5" means the same thing as "stop at 5", although it could
also be interpreted as "stop when the expression '5' changes its value"...

"dbx" has a "print" command (which can be abbreviated if you use an alias,
so it can't be argued that "sdb"s command syntax is more concise) which
prints the value of an arbitrary expression; "sdb" can print the value of a
variable, or a member of a structure or an array, but not anything more
complicated.  It also supports conditional breakpoints, which "sdb" doesn't.

> As for the command set being more limited, I thought the same thing
> from typing help in dbx, but after looking at the manual entry, it seems the
> command set is actually more extensive.

>From what I can tell, the only thing "sdb" can do which "dbx" cannot is to
dump the machine registers; you can examine individual registers, but
there's no command which dumps them all.  This would be convenient, and
could probably easily be added to "dbx".

> I admit there are bugs and problems (some of them in the manual entry),
> but I think it is a good try at writing a debugger that is easier to us
> and behaves as users expect.

I'll certainly agree with that.  Sorry, Kenneth and Doug, but "sdb" is not
comparable to "dbx", except in the sense that you can compare them and find
"sdb" wanting.  AT&T-IS should dump "sdb" and pick up "dbx" instead; if
COFF's symbol table format can's support "dbx", COFF's symbol table format
is inadequate and needs to be extended.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa	(yes, really)