Example Applications changes for GDB debugging

Sitara SDK 5.0.3 - Considerations for GDB Debugging Example Applications

 This applies to the CCSv5 Makefile projects am-benchmarks and am-sysinfo in the Sitara SDK 5.0.3

 (Nov 2011).  The makefiles for these projects require a change to allow GDB debugging to work properly.

 The original makefiles have both the -O3 (optimize level 3) and -g3 (include symbolic information - level 3)

 options included for the debug build.  This produces erratic behavior when stepping thru the code using

 CCSv5. 

 

Correction to the Makefiles (Required for GDB Debuggiong)

The following make files are affected:

<TI_SDK_PATH>/example-applications/am-benchmarks-1.3/armv7a/dhrystone/makefile

<TI_SDK_PATH>/example-applications/am-benchmarks-1.3/armv7a/linpack/makefile

<TI_SDK_PATH>/example-applications/am-benchmarks-1.3/armv7a/whetstone/makefile

<TI_SDK_PATH>/example-applications/am-benchmarks-1.3/armv7a/dhrystone/makefile

<TI_SDK_PATH>/example-applications/am-sysinfo-1.0/mem_util/makefile

The remiander of this article uses the dhrystone project.

In each of the makefiles listed above find the definition of ALL_CFLAGS in the make file.   Delete the line that contains -O3.  This line is highlighted below.

 

Find the object file rule for the release build.  Insert the -O3 option in the compiler command as highlighted in the screen capture below.   The console shows the

corrected compiler options for the Debug build configuration.

 

 

Addition of Include Paths (Optional)

The am-benchmarks and am-sysinfo projects are CCS Makefile projects.   CCS calls the external GCC toolchain which compiles and links the

program and takes care of accessing all required system header files.  But inside CCS, errors are shown because the paths to the include files

have not been specified in the CCS project files.   This is usually acceptable as is because GDB will not allow you to step into CLIB functions

anyway, since the CLIB source code is not contained within the SDK.  It only means that CCS will not be able to resolve some symbols.

To make the CLIB header files accessible inside the CCS project the following two paths can be included in the project properties.    Set the configuration

to "All Configurations" to make the change for debug and release build configurations.  Add the include paths to TI GNU C.   Paths relative to the project

within the SDK are used here.

 

Addition of Define Constants (Optional)

Again, since the am-benchmarks and am-sysinfo projects are CCS Makefile projects, all define constants that are passed to the compiler are specified

in the makefile.   For CCS to be aware of the settings of the #define constants, these settings need to be added to the CCS project.   The symbolic

debugging will take place according to the #defines as set in the makefile, but there may be #define constants that the debugger will be unable to resolve.

Set the configuration to "All Configurations" to make the change for debug and release build configurations. Add the same #define symbol definitions that are

contained in the makefile to TI GNU C.

The result is shown below.  Errors reported by CCS are all resolved.  The duplicate path warning can be ignored.  The project has both debug and release build configurations and

the CCS project defaults each to the output path where the project is located.  But this is not used, since the actual output paths are controlled by the make file.  The makefile specifies that

the intermediate files and executables go to the Debug and Release subdirectories of the project.