- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Was using CCS 6.1.3.00033 under Linux to debug a project-less program, which is U-Boot for an AM3352.
The steps were:
a) Launch a project-less target configuration.
b) Attach to the Cortex-A8 core. Download and run the u-boot-spl ELF image. Suspend execution once u-boot-spl has initialized the hardware.
c) Download the u-boot ELF image and set a hardware breakpoint on the board_init_f function.
d) Run the u-boot image, which halts at the breakpoint on board_init_f function.
However, the CCS debugger then displays <uboot_root>/board.c rather than the actual <uboot_root>/arch/arm/lib/board.c source file which contains the board_init_f function which has been linked to U-boot:
U-Boot was compiled using the gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux toolchain with the -g option to include debug information. The breakpoint properties show that CCS has correctly resolved the address of board_init_f using the absolute pathname /home/Mr_Halfword/AM3352-SOM-olimex/u-boot-2013.10-ti2013.12.01-am3352_som/arch/arm/lib/board.c, yet the CCS debugger has chosen to display the /home/Mr_Halfword/AM3352-SOM-olimex/u-boot-2013.10-ti2013.12.01-am3352_som/board.c source file, which has the same name but is in a different directory. This confuses single-stepping since the wrong source file is shown.
The Source Lookup Path under the Debug Configurations was set to the Default, which has "Absolute File Path" at the top. I tried modifying the Source Lookup Path, e.g. to remove the other options apart from "Absolute File Path", but the CCS debugger still displayed the wrong board.c source file when the board_init_f breakpoint was hit.
I realized that the incorrect board.c source file which was displayed by the CCS debugger was in the same directory as the u-boot ELF image which was downloaded. I moved the u-boot ELF image to a different sub-directory, and the CCS debugger was then able to display the correct <uboot_root>/arch/arm/lib/board.c source file when the board_init_f breakpoint was hit.
Is this a bug in CCS that when debug information contains an absolute source file pathname, that CCS appears to ignore the absolute pathname and instead display a source file of the same name which happens to be in the directory containing the image which was downloaded?
Thanks Chester.
Chester Gillon said:U-Boot was compiled using the gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux toolchain with the -g option to include debug information. The breakpoint properties show that CCS has correctly resolved the address of board_init_f using the absolute pathname /home/Mr_Halfword/AM3352-SOM-olimex/u-boot-2013.10-ti2013.12.01-am3352_som/arch/arm/lib/board.c, yet the CCS debugger has chosen to display the /home/Mr_Halfword/AM3352-SOM-olimex/u-boot-2013.10-ti2013.12.01-am3352_som/board.c source file, which has the same name but is in a different directory. This confuses single-stepping since the wrong source file is shown.
When browsing the loaded symbols via the modules view, I can see that there are three board.c references, of which the path information is relative with just the file name:
Hence I believe that it will look for a source file call board.c relative to the loaded symbol file, which is why the debugger (when halted) pull out the board.c in the same directory as the symbol file (elf image). The debugger will always try to use relative path information first (relative to the path of the loaded symbol file) when trying to open a source file in the editor when halted.
As for why the breakpoint set on board_init_f is referencing the correct board.c location, when looking in the modules view for that function:
It has the correct file path for the board.c for the debug info for the function.
I'll need to confirm with the engineers here if what I described is accurate (and more importantly if it is a bug).
Thanks
ki
