The C and C++ languages have a long history, with hundreds of host-target combinations and a wide range of established compilers and debuggers. But a lack of interoperability among those tools has been a source of frustration for developers and independent software vendors alike.

Enter the Eclipse C/C++ Development Tools project (CDT). Based on the core Eclipse platform, the CDT provides an extensible, open-source integrated development environment (IDE) designed to simplify tool-to-tool integration. Like Eclipse itself, the CDT is written almost entirely in Java and runs on multiple development hosts, including Linux, Windows, Solaris and the QNX Neutrino real-time operating system. It comes with a rich tool set, including a source-code editor, an outliner, a graphical debugger, a project-management system and a search engine for navigating code bases. Moreover, third-party tools and user-written plug-ins can extend and adapt those features to address a variety of development requirements.

Developers can readily download the CDT and use it as is. Meanwhile, independent software vendors (ISVs) can customize it for specific markets or applications. To do so, they use extension points-the same mechanism that gives the core Eclipse platform its inherent flexibility. Implemented in XML, an extension point consists of string identifiers that define a common interface for a particular set of functions. In many cases, the extension point also defines the name of a Java class that is dynamically invoked in response to a user action.

Consider the case of a plug-in that contributes a particular action when the user selects a file. To implement the feature, the plug-in developer would use the org.eclipse.ui.popupMenu extension point to define the type of object (in this case, a file) on which to perform an action, as well as the Java class to invoke when that object is selected. This is one example of how extension points can extend the functionality of the IDE framework while allowing components to remain cleanly decoupled. Other extension points are found in the table.

To target the widest audience and maintain the open-source spirit, the CDT team chose the GNU tool chain as its reference implementation. For instance, the default build system uses GNU make, the default compiler integration targets GNU compiler collection and the CDT graphical debugger integrates with the GNU debugger (GDB) command line. As a result, the CDT can support a wide range of target processors and operating systems.

While this default implementation is ideal for creating desktop or server apps, it doesn't necessarily address the needs of embedded developers. For instance, the plain-vanilla version of the graphical debugger uses the GNU gdb debugger to provide self-hosted, same-machine debugging. Such an approach is ill-suited for any embedded project where the development host employs one processor-OS combination (for example, X86-Windows) and the target system uses another (say, PowerPC-QNX Neutrino RTOS).

For such applications, the base functionality of the CDT debugger must be extended to support remote target debugging. QNX engineers achieved this by employing a combination of Eclipse and CDT extension points.

C extensions
The CDT graphical debugger adds C/C++ extensions to the core Eclipse debug framework, which provides language-independent facilities to launch debug sessions, manage breakpoints, locate source code and display such elements as stack frames and variables. The first step in adapting this C/C++ debugger for remote targets was to create a custom launch configuration.

A standard part of the Eclipse platform, launch configurations are generally used to take the results of something generated by the Eclipse framework (for instance, an application) and then apply an action to that object. By default, CDT provides a local C/C++ debugger launch configuration that lets the developer select an application, customize the arguments and environment for that application and then launch it under the control of a debugger. Launching a remote debug session requires several additional steps. These include:

• Establish a definition of the remote system.

• Establish communication with the remote system.

• Transfer the application and required files to the remote system.

• Establish a debug channel for control of the application to be launched.

• Configure the application environment on the remote system.

• Launch the application on the remote system.

• Control the remote application, using the debug channel.

• Clean up after the application terminates, normally or abnormally.

Implementing these steps required several enhancements to the CDT's basic launch configuration mechanism. By using the Eclipse launch configuration extension point, org.eclipse.debug.core.

launchConfigurationTypes, and by extending existing CDT user interface components, the project team at QNX was able to make the modifications with little effort. Currently implemented in QNX Momentics, an Eclipse-based development suite distributed by QNX Software Systems, the enhancements include:

• Configuring a communication channel to a remote embedded target agent.

• Controlling the transfer of required files to and from the remote embedded system.

• Establishing the remote environment before launching the specified application for debugging.

For the first enhancement, the project team took advantage of an existing CDT mechanism for defining a remote target, including the target's Internet Protocol address. The team created a launch configuration that lets the user choose from existing targets or add a new definition.

For the two other enhancements, the team took advantage of the QNX Momentics target agent, which provides file transfer and application launch capabilities for tools that are running on the development host. The target agent offers a rich set of capabilities that were exposed as user interface launch configuration panels within the CDT framework. Using these panels, the user can determine:

• The absolute path (from the target's perspective) of the executable binary to be launched in the debugger.

• Information for launching the application from the IDE, namely the environment variables to set before launching the application and the command-line arguments to pass to the app.

• The host location and target destination of any ancillary files (for instance, shared library and configuration files) that the application may require.

• A process identifier for attaching the debugger to a process already running.

The designers of the CDT debugger framework understood that while the default implementation of the CDT requires only one local debugger, some ISVs would require multiple debuggers, each with different capabilities. For instance, the QNX Momentics suite supports several debuggers, each tuned to the nuances of a particular processor architecture. Moreover, the debuggers are built for environments where the host and target are separate machines connected by a communication channel.

To accommodate support for multiple debuggers, the CDT provides the org.eclipse.cdt.debug.core.CDebugger extension point, which lets the user select a debugger that matches the processor architecture and communication medium specified in the launch configuration. Consequently, it was a simple matter for QNX engineers to specify several additional targeting debuggers.

Framework particulars
The CDT debugger framework is split along several major interface lines, including the C/C++ Debugger Interface (CDI), which serves as a generic interface to all debugger clients. Specific debuggers can implement the subset of the CDI interface that makes sense for them. The default implementation of CDI also uses the GNU gdb debugger Machine Independent (MI) interface, which provides a standard way for external tools to control and communicate with gdb.

Since customized versions of gdb exist for a variety of OS and processor architectures, the authors of the CDT debugger created several reusable components, including a generic MI command processor and interpreter, that users can extend for custom implementations. Consequently, QNX engineers were able to replace the generic gdb launch component with a component that launches specialized processor-specific versions of gdb, each with a different name and command-line arguments. Once launched, a custom debugger can use the MI command and interpreter layer to access the full capabilities offered by the default implementation of gdb.

By using just two extension points provided by the Eclipse framework and plug-ins, QNX engineers extended the "generic" Eclipse CDT environment to create a useful platform for building remote embedded applications. This stands as a testament to the flexibility of both Eclipse CDT and the Eclipse core platform; but, more important, it underlines how the tool-to-tool integration afforded by such an architecture can help make developers' lives easier and more productive.

Developer perspective
Instead of having to switch environments as they move from one development task to another, developers can have constant access to the tools they need. Moreover, tools that were once isolated from one another can, through Eclipse extension points, share information and extend one another's capabilities without need for manual intervention. Such integration further improves workflow, helping developers to focus more energy on what's important: writing good software.