The open-source Eclipse project has turned into one of the primary software development platforms for Web services, embedded systems, and other applications. Embedded developers typically take advantage of the Java-based Eclipse integrated development environment (IDE) using the C/ C++ Development Tool (CDT).
Embedded tool vendors quickly adopted the CDT because it enabled incorporation of the GNU toolchain as well as proprietary toolchains including compilers, linkers, and debuggers. Using different compilers and linkers in this environment is relatively straightforward regardless of their source since the typical interaction is choosing configuration options from one or more dialog boxes. On the other hand, debuggers require a sophisticated user interface that needs to account for the features of the debugger as well as for how it presents data and controls the application being debugged.
Vendors moving to Eclipse used the GDB debugger that comes with CDT or made their proprietary debugger work with Eclipse, which was relatively easy using GDB as an example. The problem is that each vendor’s solution is different so the commonality that Eclipse brings to the equation is lost. Still, vendors and users rightly loathe to give up the features found in these debuggers. Also, proprietary debuggers tend to be opaque, so customization within the Eclipse environment tends be limited.
The approach to CDT worked well in getting vendors to adopt Eclipse, allowing the debugger to be a black box from Eclipse’s perspective. A more generic solution would make debugging more consistent. It would also make it easier to support new backends.
GENERIC DEBUGGING PLATFORM Enter the Debugger Services Framework (DSF). It is being developed by a number of contributors, including Wind River’s Pawel Piech. DSF uses the OSGi framework that Eclipse is built on to break apart the monolithic solutions starting with GDB into a more decoupled, layered approach (see the figure). It is also designed to improve the interface to remote debug targets and to expose more of the hardware. Further, it’s designed to make improvements for features such as multicore debugging easier to accomplish within a heterogeneous debugging environment.
DSF uses adapters for everything from data delivery to control and on-screen rendering. This provides a more flexible, reusable system where hopefully proprietary debuggers can deliver unique debugging-related content while utilizing common interfaces.
The adapter system permits communication with adapters using synchronous or asynchronous calls, which is key since remote debugging imparts a delay due to communication latency. It also allows a debugger to remain responsive while managing multiple cores, debug sessions, and other activities commonly found in the more complex multiprogramming environments where applications now live.
DSF and DSF-GDB are just starting out, though the project itself has a long track record. The latest GDB 7 shipped with DSFGDB support. It will take time for vendors to migrate to DSF. But the popularity and extensibility of the Eclipse environment epitomize the payoff in the long run.
Reprints
