Using GDB with OpenAccess
From oacwiki
| Running gdb (or other debugger) with OA code |
|
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)

