I don't remember dbx appearing in our lab, but that doesn't mean it wasn't there.
I did quite a bit of work on adb, renamed db, mostly finishing things up and fixing a lot of bugs, to make it actually work in Plan 9. I had several conversations with Steve Bourne about it to understand why it seemed broken, and how to fix it. Once fixed, It could do some remarkable stuff but nobody but me seemed to care because it was lower level than cdb/sdb/gdb. I liked it because, once those bugs were fixed, it got the right answer, something gdb never did back then. The [scg]db of yesteryear was far too unreliable and crashy for me. After it dumped core for the nth time on top of the core I was debugging, I gave up on it. But I was never a debugger-first programmer. None of us in the lab were, and that's probably why the debugging setup in Unix is to this day so weak compared to what other systems provide.
The sdb/gdb line also had a peculiar property of not answering the question you were asking, although I don't remember the details. It was more interested in the symbols than the code, and that could get in the way. The failure of the compiler to give good symbols didn't help. And now we have DWARF, for which my only comment is: oof, the sound one makes catching a dropped bag of concrete mix.
One debugger that we used a lot, although more as a scripting language for things like tracing system calls and checking for malloc leaks than as an interactive tool, was Phil Winterbottom's Acid. It has a crazy language but once you licked it (I think the only three who did were Phil, me, and Russ Cox) it was very powerful. Acme had some front-end code for it that made it great for displaying multithreaded program stacks.
Pi was cool, but that was earlier and tied to the Jerq/Blit and C++.
-rob