Into this post I will briefly explain how to connect a CDT Eclipse project to a remote target based on a Linux embedded distribution to achieve step-by-step debugging.
Mandatory precondition is to have either gdb or gdbserver present on target Linux distribution: this utility will control program execution and communicate remotely with host PC usually through an ssh connection on port 2345. On host PC side, Eclipse CDT gives graphical front-end that uses gdb from cross-compiler toolchain (as example for PowerPC or ARM targets) to show your application execution into a user friendly environment: it is possible to insert breakpoints, watchpoints, perform step-by-step execution, heap and stack memory analysis, with regards of usual difficulties while debugging embedded multi-thread applications.
Prepare the target
On embedded board side it is mandatory to change your start script to do not launch automatically application (remote debug on running application is possible but not covered here). You should of course set-up network interface to communicate with host PC: you should be able to successfully ping it and enable remote console access. There an ssh server daemon is considered as primary way of communication, but you could also setup a simple telnet + ftp scheme.
As we’ll see in a short time, graphical front-end can be configured to automatically download executable to launch: it is better to reserve a “Debug” build configuration for such purpose.
Executable build configuration
Better is to reserve a build configuration for debugging purposes to avoid optimizations (-O0 gcc option), to include debugging symbols (-g3 option) and to get rid some functionalitites to may interfere with debugging operations (watchdogs, handler on SIGINT, etc…). Conditional compilation could be easily performed through definition of a “DEBUG” symbol (-DDEBUG compiler option) to remove part of code using #ifdef/#ifndef prepocessor statements. Please follow documentation about gcc compiler option for more details (link).
To use support for remote Linux debugging must install related plugin, on Eclipse follow “Help > Install New Software …” menu and select database for your installation (example “Mars – http://download.eclipse.org/releases/mars) then wait a little bit for plugin list to update. Now go into “Mobile and Device Development” and select plugins like on figure (note: if already installed these entries are masked unless you select otherwise on checkbox “Hide items that are already installed”) :
Eclipse remote development pluginNow it’s time to add a debug configuration for remote debugging: select menu “Run > Debug Configurations …” and follow on the left side “C/C++ Remote Application” then press “+” icon on the top to generate related configuration. Pay attention: while build configurations are stored into Eclipse project files, debug configurations are stored into .”workspace” hidden folder. That means you should either copy this configuration from one workspace to another or set a fresh new one on each workspace (quite a boring task, indeed).
Let’s go ahead with debug configuration settings: into “C/C++ Application” field now insert path to executable into your host machine, then into “Remote Absolute File Path” you shall specify where to download it (in some target you would probably prefer to download into a path mounted as RAM filesystem, to accelerate download operation and save flash writing cycles).
On the bottom of this screen, be sure using “GDB (DSF) Automatic Remote Debugging Launcher”, otherwise can select one by use of “Select other…” link.
You still need to specify a mean to connct to remote target, on “Connection” select “New…” and select you preferred options (I usually select “SSH only”) with target IP and user autentication details.
GDB host side Debug configuration
Let’s go ahead with “Debug Configuration” settings page, you shall now select “Debugger” tab to allow Eclipse to know which GDB installation to use, most probably here you shall select path of your cross compiler binaries. You should then specify also a .gdbinit file which at least contains the following 4 lines:
handle SIG32 nostop handle SIG32 noprint handle SIG33 nostop handle SIG33 noprint
Into “Shared Libraries” tab could select path for dynamic libraries to load their symbols, these paths must be absolute so this section is not exactly portable from one host environment to another.
Eventually, “gdbserver” settings tab can be leaved with default values (communicate on port 2345).