Debugging on smaller form factor devices like tablets, handsets, and other Intel® Atom™ Processor-based platforms requires a shift in the debug paradigm from native debugging to the cross-debug methodology more commonly used in the embedded world. This technical note shows the convenience of doing this using Intel's debug solution.
Finding problems quickly so they can be resolved quickly is helped by having an Eclipse*-based graphical user interface. Ideally you want to have application threads and all the variables and data structures in yor application visiable at the push of a button. This is what developers are used to in the desktop centric native development world.
If the device you are developing for is too small for convenient use of a full-blown graphical debugger solution, the best solution is to debug remotely.
This is done by establishing a debug message protocol and using an interface like TCP/IP for communication between host development system and the target system, where the application to be debugged actually runs. The communication between host and target needs to provide all the information about application load location, process id number, shared object dependencies and load locations, execution state and memory layout to the host development system. This is achieved via a small debug handler application running in user space on the target. It usually idles in user space memory and gets triggered by a dedicated debug interrupt. This is when it starts sending status information via a dedicated TCP/IP port to the host system where the debugger itself is waiting to pick up the data it receives. The debug interrupt could be caused by a breakpoint or data watchpoint being hit. It could also be triggered by an explicit action on the debug host. The developer telling the debugger to attach to a specific running process or telling the debugger to stop a specific thread.
One basic precondition for cross-debugging is that you do not only need to have the application runnint on the target, but you also need to have access to the application sources and the symbol info (on a Linux system inside the ELF-Dwarf executable) on the host. Simply applications can be deployed onto the target using the debugger. Generally it is probably recommendable to just copy and install the application on the target using ftp or a similar protocol.
Starting the Intel® Application Debugger
When you start the remote server on the target system (whether it may be an actual hardware target or a MeeGo* developer image running inside a KVM* virtual machine) it will respond with a sign-on message on the console of the target system.
You are now ready to start the Application Debugger on the host system. Look for the idb.sh file in the /opt/intel/atom/idb/x.x.xxx/bin directory. You can start the Application Debugger with the following command:
$ cd /opt/intel/atom/idb/x.x.xxx/bin <cr>
$ ./idb.sh <cr>
The Application Debugger will open up for the first time with an empty window with a menu line with most buttons grayed out and below a Console window. If it has been used before it opens with the same window layout as when it was closed. Only the Console window will contain any data – the sign in message.
Below the Console window you find a status bar. In the middle you have an indication of what mode of operation the debugger is in.
In the menu you have a few symbols active. One of them is the ‘Connect ..’ button. Click on it to connect to the remote server on the target. You will see the Open Connection dialog where you can enter the IP address of the target system. You can also debug an application running on your host system. In this case you still need to start the remote server (on the host system) and connect to it via the IP address illustrated in the screen shot below:
The port number should be the same as the one used when the remote server was started. It is possible to have more than one Application Debugger running - each would be connected to a remote server with different port number. This allows you for example to debug an application both on the host and target at the same time.
On the host system the debugger GUI will be updated to illustrate that you now are ready to attach to a running process or load a new application.
If you decide to load an application a pop up window will appear where you can browse for the application binaries, specify any specific environment variables you need and specify where the source files are (if in a different directory than the binary):
You need to check the ‘Upload’ box if you want the debugger to copy the file over to the target system. In the ‘Target Executable File’ field you enter the location on the target where you will store the executable. Make sure that all directories you specify already exist on the target system and that the file name is the same as specified in the ‘Executable File’ field. (The location on the host and target can be different but the file name should be the same). When you press the OK button it will take some time after which the status indicator will change to yellow. You are now ready to start debugging.
You can set a breakpoint by just double clicking on any of the blue dots to the left of the line numbers in the Source window. Note that if you select line 8 (in the screen shot above) you are outside of the stack frame from main and hence have no access to local variables.
Another very useful window is the Callstack, where you can see the path through the function calls you have taken to reach your current position in the code. You can open the Callstack window by selecting View/Callstack from the debugger menu or typing Ctrl+Alt+R:
Additional windows which might be useful are the Register, Locals and Threads windows. The Register window is opened with View/Register or Ctrl+Alt+G and shows the current values of the segment registers, general purpose registers, floating point registers and the xmm registers. The Locals window shows the local variables and is opened with View/Locals or Ctrl+Alt+V. The Thread window is particularly useful if your application is multithreaded. It shows which thread you are currently debugging. You open this window with View/Threads or Ctrl+Alt+T.
In short, once you accept the basic paradigm of cross-development and cross-debugging as it is commonly used in the embedded world for your mobile device-targeted development work as well, developing is just as seamless and straightforward has you have always been used to.