Oracle Solaris Studio: Did you know? dbxtool is back - Solaris Rss

This is a discussion on Oracle Solaris Studio: Did you know? dbxtool is back - Solaris Rss ; I'm seeing as I hear more and more from customers that few of them are aware that DBXtool has come back as an independent, standalone tool in Studio . This blog is a note to get the word out, but ...

Oracle Solaris Studio: Did you know? dbxtool is back

I'm seeing as I hear more and more from customers that few of them are aware that DBXtool has come back as an independent, standalone tool in Studio. This blog is a note to get the word out, but while I'm at it, let us look at it in somewhat greater depth.

History of Dbxtool: OK, its inevitable that the re-emergence of DBXtool is tied to past history. So, lets peek a bit at the last 20 years. I remember back from the mid to late 80s when Sun's introduction of a desktop Windowing system called SunView featured a graphical debugger called dbxtool. dbxtool was a simple, easy to use interface to the source-level debugger, dbx. [I am amazed that you can still find references to it on the web!]. Personally, I found dbxtool to be a huge productivity enhancer and used it more than any other graphical productivity application (other than perhaps email!). In particular, I remember cool commands like "button expand" that let you create your own buttons in the panel. In the early 90s, Sunview evolved into a short-lived but very interesting project called NeWS. But more significantly, as Sun upgraded to the Open Look feel, dbxtool was rewritten for the new look-and-feel, so that events like Breakpoint-controls and Execution, Stack and Data display properties all had their own menus. From here on, dbxtool (now called simply: Debugger) was increasingly integrated into a programming environment which included editors-of-choice (vi, xemacs, nedit), a source browser, a build system and a source code management system (called Teamware). The debugger could still be invoked individually, if so desired, but it was all in the context of a larger toolset called Workshop. Workshop was an immensely popular product in the mid 90s for Sun's developer tools offering and to this day, many of Sun's enterprise customers fondly remember it.
But Sun was also undergoing a lot of change (particularly: Java, in this context) and in a quest to get a state-of-the-art IDE and to allow programmers to use the same tools for Java and C/C++, Sun bought a Czech company called NetBeans. This IDE had its own strong notion of workflow, learning much from the Microsoft and Borland models of tightly-integrated edit-compile-debug cycle support. The tools were all tightly integrated and Workshop went through three more name changes before finally settling in on the Sun Studio name(Workshop -> Forte Developer -> Sun ONE Studio -> Sun Studio). The Workshop group integrated C/C++ language support into NetBeans and thus made this offering equally complete and competitive for C/C++ users as well.
Since the late 90s and throughout this decade, the debugger has lived inside the (NetBeans-based) Studio IDE. Which is great. However, not everyone in Unix likes an IDE. In particular, many of them want simple, standalone tools. Make, SCCS/TeamWare, Source Browser etc. all evolved in Unix/Solaris from this strong need. So, despite a fairly strong undercurrent of demand for a lightweight, standalone tool for debugging, this has been available only through the IDE. Finally, in 2009, Studio released a standalone debugger, dbxtool to satisfy this constant demand.

What is in Dbxtool? Three things are different from the debugger in IDE. First, dbxtool is standalone and only loads the modules needed for debugging (and thus has faster startup and is lighter in memory usage). Second, dbxtool can be used to directly act upon a binary without having to create a project. Finally, you can embed dbxtool invocation into shell scripts and driver programs (via ss_attach) and do "dbx-specific" things like debug corefiles, debug process-ids without an executable, etc. Thus dbxtool more closely mimics the functionality in dbx, while preserving the advantages and convenience of graphical look-and-feel.
In dbxtool, you can look at stack traces, register dumps, [dis]assembly of corresponding source, watchpoints, multiple thread execution states, examining variables, and perform extensive expression evaluation.
Among other things that you might not know about, Dbxtool does runtime memory checking, allows for multiple sessions and does remote debugging (Solaris/Linux Client to Solaris/Linux server).