Services - tools - models - for embedded software development
Embecosm divider strip
Prev  Next

5.1.  Debugging using OpenRISC GDB via RSP and Or1ksim


With the introduction of the GDB Remote Serial Protocol interface in GDB 6.8 release 2.0 for OpenRISC 1000 and Or1ksim 0.3.0rc2 remote debugging has changed considerably. The instructions here have changed significantly since the last issue of this application note.

This requires the GNU debugger built for cross platform use with OpenRISC (see Section 3.3). Or1ksim contains some guidelines in the file README.gdb in its main directory, but these relate to the old GDB 5.3 version. The definitive instructions are in the GDB User Guide [1].

To use the remote debug feature of Or1ksim, enable the debug section in the simulator configuration file. Set enabled option to 1 and rsp_enabled option to 1. The server port is not chosen at random, but set by the server_port option here. Good practice would recommend using a value in the Dynamic Range (49152-65535), such as the 51000 used in the default configuration file. Or1ksim should be started without specifying any image file.

In a separate window start the OpenRISC 1000 GDB command (or32-uclinux-gdb).


For those who like their debugging to be graphical, it is perfectly feasible to run GDB under DDD. The following would be a suitable DDD command line.

ddd --debugger or32-uclinux-gdb --gdb

There are three stages to setting up GDB.

  1. Load a local symbol table (using the GDB file) command.

  2. Connect to the remote simulator via RSP (using the GDB target) command.

  3. Load the program on the remote simulator via RSP (using the GDB load) command.

A typical set of commands (once inside GDB) to debug a simple "Hello World" program on Or1ksim on the same machine, with RSP connecting through port 51000 would be:

file hello_world
target remote :51000
load hello_world

At this point the usual GDB commands to breakpoint, continue and examine programs are available. This includes symbolic disassembly of the code.


GDB connecting through RSP with target remote is connecting to a target which is already executing, but has stalled. Thus it is inappropriate to use the run command (which specifies a new program to run). Instead the continue and step commands are used.

The load command will reset the program counter to the entry point of the program. So a subsequent continue will cause the newly loaded program to execute from its entry point.

Embecosm divider strip