Debugging Waveform Components

Question

RedHawk IDE has supports debugging with gdb integrated into the IDE but the manual only discusses doing this with the sandbox. Gdb inself, of course, is able to attach to an already running process and even attach to a process running on a remote machine. Is it possible to use gdb as integrated in RedHawk/Eclipse to debug one of the components in a running waveform launched in a domain on the local machine or a remote target or must I just use gdb outside RedHawk with the integration?

Answer 1

Debugging in a live domain requires several steps to get your component to run in a debugger. It's not the most straight-forward, but it's doable, and sometimes the only way to debug a behavior if you need it in a production environment and not the sandbox. I've used these steps with the REDHAWK 1.10 series.

First you'll need to reconfigure the component to launch via a script. This is based on the code generator template for Java components, if you're looking for an example. You'll want to add a new file to your project's implementation folder ('cpp' in my example) named debug.sh. Add the following contents:

#!/bin/sh
mydir=`dirname $0`
chmod +x ${mydir}/your_component_executable
exec gdbserver host:2345 ${mydir}/your_component_executable "$@"

Replace your_component_executable with the name of your component. Now, you'll need to make sure that a 'make install' installs this script. Add the following to your Makefile.am:

bin_SCRIPTS = debug.sh

Next, edit your .spd.xml file. Modify the localfile and entrypoint elements. The localfile element tells REDHAWK what the ExecutableDevice (i.e. your GPP) should copy over to its file system to be able to run the component. The entrypoint is what actually gets exec'd to start the process. After modifying, it might look something like this:

<code type="Executable">
  <localfile name="cpp"/>
  <entrypoint>cpp/debug.sh</entrypoint>
</code>

Notice the localfile now points at the implementation directory (not the executable file), and entrypoint points at the debug.sh.

Now, make sure that gdbserver is installed on the machine that will end up running the component (the machine with the GPP). For example, on CentOS 6:

sudo yum install gdb-gdbserver

For the next part, you'll actually want two IDEs open. With #1, we'll debug the component. With #2, we'll perform domain-functions. I'll assume you have your component as a project in your workspace in IDE #1.

In IDE #1, install your component to the target SDRROOT. Next, select your project in the Project Explorer, right-click, and select "Debug As" -> "Debug Configurations...". Double-click "C/C++ Remote Application". A configuration will be created and populated with your component project's details. Switch to the "Debugger" tab, and select the "Connection" tab under "Debugger Options". Change the host name to match the GPP where the component will run (if not on your localhost), and change the port to match the debug.sh script file (2345 in my example). Leave this dialog open.

Switch to IDE #2. If you need to, start your domain and a device manager with a GPP (right-click "Target SDR", select "Launch..."). Launch the waveform containing your component (right-click the domain, then "Launch Waveform..."). You'll notice that the launch dialog will pause waiting for the waveform to launch. This is because your component has paused in the main() method waiting for the debugger to connect, and it hasn't registered with the domain.

Switch to IDE #1. Click the "Debug" button on the dialog. You should be connected to the process, and the IDE will prompt you to switch to the debug perspective and you will see you're in your component's main() method. The component needs to regsiter within 60 seconds or the framework will assume it failed to launch and timeout. I normally click the run button to allow the component to complete its initialization. You'll see the launch complete in IDE #2, and a diagram for your waveform pop open.

At this point, it's easy to set breakpoints in your code (especially the service function, property change notifications, etc) and debug. If you have items you need to debug during the initialization phase of your component, you may need a custom installation of the framework which is modified to not timeout waiting for components to register.

Answer 2

I adapted the script to examine the properties passed to the component when exec'ed and decide whether to exec it under gdb or directly. This allows the script and the change to spd.xml to remain in place and debugging turned on or off by adding or removing a property in the component's property page. My property when present also specifies the port gdbserver should use and also allows specifying which instance to debug if the component has more than one instance in the waveform. I use a property gdbn to debug the n'th instance. This makes debugging components running in a domain much more practical.