I HATE DBX! I HATE DBX!

[Mark Plotnick]

In article <4473 at think.ARPA>, massar at think.ARPA rants and raves
("raves" is possibly not the right word to use here) about dbx.

The vanilla 4.2bsd dbx gave "<variable> is not active" errors when you
were stopped inside a nested block because its findframe() routine was
a bit simplistic.  It just walked down (or is it up - we're talking
about a vax here, after all) the stack by following the saved frame
pointers.  Mark Linton, the author, posted a large set of diffs in 1984
that fixed this and many other bugs (briefly, it needs to check if the
current function is an "inline" function, and if so should look at its
"container" rather than blindly calling nextframe()).

One problem I've found in the 1984 version and the 4.3bsd-beta version
is that occasionally dbx will get confused when the PC is in
sigtramp-land (somewhere above your stack base, around the u area).  It
prints the arguments to the current function (in my case, this is
typically a select() that's been interrupted by an alarm or int signal)
correctly, but claims the name of the function is sbrk or printf.  It
then frequently doesn't give a stack trace longer than one function.  If
anyone has a fix for this, let me know.

While we're on the subject of dbx bugs, you may want to change
the restoretty() function to do
	ioctl(fileno(f), TIOCSETN, t);
rather than
	stty(fileno(f), t);
so that when a signal that's not being caught by dbx comes in (for
instance, dbx normally does nothing with an alarm signal except reflect
it back to the process), your pending typein won't get flushed.

	Mark Plotnick
	allegra!mp