Running Debuggers with OpenAccess

From oacwiki

Debugging OA supplied applications can be difficult because each OA application is driven by a script. For example, when the command oa2strmis given, the script named oa2strm is executed. It sets up the library path, which tells the loader where it is supposed to look for the OA shared libraries. It then calls the RunExe script to select and run the appropriate binary, depending on the architecture and optimization level required.

In order to run an OA executable within a debugger, you will need to do all of the setup of the library path yourself. You will also need to find the right binary because the debugger needs to invoke the binary itself, not the wrapper script.

An alternative to setting everything up yourself is to modify the scripts so that after setting everything up, they can optionally invoke the debugger instead of directly invoking the binary. For example, the following change to RunExe will optionally run the ddd debugger for any of the OA applications:

 ### run the program
 if [ "$DDD" == "ddd" ]
 then
     ddd --args $INSTALL_ROOT/bin/${SYSNAME}_$BIT/$MODE/$PROGRAM "$@"
 else
     exec $INSTALL_ROOT/bin/${SYSNAME}_$BIT/$MODE/$PROGRAM "$@"
 fi

When running an application, if the environment variable DDD is set to ddd then the ddd debugger will be invoked and ddd will then run the application program.

---

[added by Kevin Grant, Freescale Semiconductor]

Note (on Unix platforms) that this is avoidable if the shared libraries are built so as to embed a "run path". I believe, at least at sites where OA is built from source, that this should be an option available to those building OA locally.

For example, in GCC, the linker option -rpath can be used. Say I installed OpenAccess into /opt/OpenAccess/lib/linux_rhel30_32/dbg; my compile line might include:

   gcc (other options) -Wl,-rpath -Wl,/opt/OpenAccess/lib/linux_rhel30_32/dbg
 

This hard-codes the location of OpenAccess shared libraries into the executable. They are therefore *automatically* found at runtime - that is, LD_LIBRARY_PATH is not needed and the executable can be directly run (no script) and debugged. On Solaris or Linux, one could run the "ldd" command to verify the libraries used, e.g.

   ldd oa2strm
       liboaBaseD.so => /opt/OpenAccess/lib/linux_rhel30_32/dbg/liboaBaseD.so (0x005ea000)
       liboaCommonD.so.1 => /opt/OpenAccess/lib/linux_rhel30_32/dbg/liboaCommonD.so (0x00d9a000)
       . . . .
       /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00d45000)