Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
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
Correction to the Makefiles (Required for GDB Debuggiong)
The following make files are affected:
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.