Oct 5

Since Geany provide a nice wrapper around the cammand line based compiler environment, I guess there will be a simular solution for the commandline based debugger. The first step to take in order to find a nice IDE is than the same as for Geany, in the Applications menu from Ubuntu click the Add/Remove… option. In the search field enter debug and click on the popularity column. The first found graphical user interface for GDB is KDbg, select it and click the Apply button in order to install it. This adds a shortcut in the Applications | Programming menu next to Geany.

After starting KDbg the first thing to do it is to make sure that debugger that will be used is not the PC-based debugger but gdb-cris. The Settings menu has an option Global settings, in the debugger tab an input line is available “How to invoke GDB”. It states gdb –fullname –nx so by default it uses gdb as a debugger. In order to use gdb-cris by default, replace this with /usr/local/gdb-cris/gdb-cris –fullname –nx and press the OK button. I’m not sure what the options mean but they were there so better leave them.

Since the debugger will be called using the Makefile it must be possible to launch it from the command line. Therefor close KDbg and open a terminal. Giving the command kdbg — help shows all available command line options. Specially the -r option for remote debugging via an interface is helpful since it must connect to the FB using gdbserver using a network connection. In the tips page of the KDbg site this is explained in more detail, using the command line kdbg -r FOXBoard:1234 Hello_World should connect to the FB, before giving this command first open a second terminal and start gdbserver Hello_World, the terminal will state that dbserver is listening on port 1234 for remote commands.

Second, navigate to the folder holding the executable Hello_World, in my case /home/jan/FOXBoard/HelloWorld. In this folder now enter the command kdbg -r FOXBoard:1234 Hello_World. This will start KDbg, indeed a connection is made to the FOXBoard since gdbserver reports Remote debugging from host, apparently I have a different IP address that previous (158 in stead of 157), but gdbserver does not seem to mind, it accepts any command from any server.

In KDbg, no source file is opened, this is not so nice, I was hoping that main.c was opened automatically. Something to investigate later, for now the file is opened using the File | Open source… menu. By clicking in front of the plus-sign on the line containing int main () a red dot is added indicating a breakpoint has been set. Selecting the Execution | Run menu option shows a green arrow at the first line of the program. Selecting the Execution | Step over or pressing F10 executes one line after another, the output of the Hello_World application is displayed in the terminal from gdbserver. When the end of the application is reached selecting Execution | Run menu or pressing F5 will finish the application, the gdbserver terminal indeed reports that the child has exit with status 0. Nice!

After playing sometime with KDbg, I’m missing some functions. For one, when the application on the FB terminates it would be nice to re-connect to the FB when gdbserver is started again. The only way to connect now it to close KGdb and start it again. All debug commands in KDbg are disabled when the gdbserver terminates. After restarting gdbserver there is a command Execution | Attach available that prompts for the process ID to connect to. Typing FOXBoard:1234 is accepted, all debug commands are enabled but gdbserver does not detect that KGdb is trying to connect. Since no errors are reported it is difficult to see what commands are executed, however there is another command line option available to specify a file that is used for logging all gdb commands.

Close Kdbg and restart it now using the command  kdbg -r FOXBoard:1234 -t Dump.txt Hello_World, after executing and restarting the application with gdbserver now again the command Execution | Attach is given. After this Kgdb is closed and the file Dump.txt is examined using the command gedit Dump.txt, this file indeed shows a lot of messages that were given to gbd. It also shows that the correct version of gdb is used (This GDB was configured as “–host=i386-linux –target=cris”) and many more (usefull) gdb commands. At the end, it states attach FOXBoard:1234 that (I guess) was triggered by my attach action. The response of gdb is “Don’t know how to attach.  Try “help target”.”, so that is why it does not work. Closing Kdbg and starting gdb-cris in a terminal window shows the same responds. After several tries the solution is very simple, in Kdbg simply reload the executable using the File | Recent executables… menu option, after the reload gdbserver replies with Remote debugging from host and debugging starts from the first line again.

The second option that I’m missing is to restart the application half way the debugging process. There is a Execution | Restart menu option but this shows the gdbserver is being killed, so no restart. Investigating the file Dump.txt again shows a run command is given in gdb when selecting the restart menu option. Also here checking what gdb-cris does result in a question (after the run command halfway the debugging) that “The program being debugged has been started already. Start it from the beginning? (y or n)”. A very valid question, answering this with y kills the running instance of gdbserver followed by the previous complaint from gdb “Don’t know how to attach.  Try “help target”.”

Since the response is the same, perhaps the solution is the same? Halfway the debugging process in Kgtb the executable is reloaded using the File | Recent executables… menu option. Gdbserver reports that the remote side has terminated the connection and that it will re-open the connection. Not exactly what I was hoping for since the debugging does not start at the beginning but were it has been stopped.

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.