Using GDB with OpenAccess

From oacwiki

Jump to: navigation, search
Running gdb (or other debugger) with OA code
 UP↑ to OAC Public Wiki 

Debugging OpenAccess Translators

Debugging OA-supplied translator applications can be difficult when run from their script wrappers (located in the $OA_ROOT/bin directory of the OA install root). Those script wrappers are commonly used because they set various environment variables needed for proper linking and loading of the actual binary executable (which is in a different bin/ subdirectory). Those scripts further call 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 perform those variable settings manually, and choose the right translator binary for the debugger to invoke (instead of 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)


Personal tools