| Can't locate source code while debugging GCC Arm device [message #1729315] |
Tue, 12 April 2016 17:00  |
Eclipse User |
|
|
|
This is a statement of the problem and the proposed resolution.
Problem: Debugger sometimes can not locate source code for GCC Arm cross-compiler
It may be more appropriate to alert TI rather than XDCTools, but the issue affects the XDCTools community as well.
I am using this compiler supplied from TI's Code Composer Studio:
gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc. I suspect it affects all versions of this cross-compiler.
The makefile commands are created by _utils.xs in package gnu.targets (supplied by TI-RTOS). The one to compile is:
cmd = prefix + ccCmd
+ " -x c $(ASMONLY) " + cmdOpts + " -o $@ $<";
When the source code files are in a different directory other than the package directory, the explicit full filename is expanded by make ( the '$<' part) and so it gets passed to the arm-none-eabi-gcc compiler. When the source code file is in the same directory, or a path relative to the package directory, the shortened name will get passed to the gcc compiler and the debugger will not be able to locate it.
I was able to fix this by changing the code to explicitly emit the fully qualified filename which includes the path.
cmd = prefix + ccCmd
+ " -x c $(ASMONLY) " + cmdOpts + " -o $@ $(realpath $<)";
Oddly, the gcc compiler used by Mingw doesn't have this issue, and it is able to locate the source file just fine, even if it was not passed the full absolute filename.
Perhaps this is an issue with how the object library debugging information is stored using the dwarf format ?!?!
I couldn't seem to find a compiler flag that would do the same thing, so I needed to change the .xs script. If there is a flag I can use, I would love to know.
Thanks
|
|
|
| Re: Can't locate source code while debugging GCC Arm device [message #1729413 is a reply to message #1729315] |
Wed, 13 April 2016 20:17  |
| Eclipse User |
|
|
|
James,
as a rule we use relative paths for everything inside a package, which then makes packages relocatable. There are cases, as you noticed, where an absolute path would show up for files outside of the package. But, if a package is released and moved you don't want those other paths to be relative anyway because packages are not guaranteed to be relocated together.
As for Dwarf tags, I don't really know what tags are debuggers using but running objdump --dwarf=info on an object file gives me this info (I deleted a part of the absolute path):
Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_producer : (indirect string, offset: 0x8045): GNU C 4.7.3 20121207 (release) [ARM/embedded-4_7-branch revision 194305]
DW_AT_language : 1 (ANSI C)
DW_AT_name : (indirect string, offset: 0x7f1): package/cfg/app_pm4g.c
DW_AT_comp_dir : (indirect string, offset: 0x621c): /<absolute path>/src/xdc/tools/configuro/tests/m4/app
I am not sure what Mingw does, but are you using the same debugger in both cases? Might be a difference in debuggers.
There is a this thread (9 years old though), which hints that DWARF tags are not the only place where gdb looks for the source path:
http://gdb.sourceware.narkive.com/n0xtZ9aw/gdb-mis-behavior-depends-on-dwarf-dw-tag-compile-unit-data
|
|
|
|
| Re: Can't locate source code while debugging GCC Arm device [message #1730022 is a reply to message #1729518] |
Wed, 20 April 2016 21:16 |
| Eclipse User |
|
|
|
James,
I just tried that and the CCS debugger found Mod_create() call in package/cfg/*.c file. My code is also built and compiled outside of CCS, and I only used CCS for debugging. I used the different compiler this time to match yours:
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x3e1): GNU C 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147] -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mabi=aapcs -g -O2 -ffunction-sections -fdata-sections
<10> DW_AT_language : 1 (ANSI C)
<11> DW_AT_name : (indirect string, offset: 0x4062): package/cfg/client_pm4fg.c
<15> DW_AT_comp_dir : (indirect string, offset: 0x5b87): D:\scratch\gccM4Example
I really don't know much about the CCS debugger, so I can't explain why it's working for me. I know that the debugger has an option Window->Preferences->C/C++->Debug->Source Lookup Path, but I don't see anything there that would make my example work. There is a CCS forum on the TI website, where you could probably get more help: https://e2e.ti.com/support/development_tools/code_composer_studio.
|
|
|
Powered by
FUDForum. Page generated in 0.04969 seconds
Home