• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 54 subscribers
  • Views 465 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS5 fails to load symbols from GCC executables.

Yulin
Expert 1625 points


Hi there,

Executables built using arm-arago-linux-gnueabi- and arm-linux-gnueabihf- are attached.http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/81/5516.uboot.7z
u-boot.arm-arago-linux-gnueabi is built by arm-arago-linux-gnueabi- and source is ~/IPNC_RDK_DM385_v3.5.0/.../u-boot
u-boot.arm-linux-gnueabihf is built by arm-linux-gnueabihf- with TEXT_BASE = 0x40300000

CCS5 (all v5.4/v5.5 linux/win) fails to load symbols from GCC executables (u-boot.arm-linux-gnueabihf) as shown below:

Regards,

Yulin.

  • 0
    TI__Guru**** 171299 points

    Yulin,

    Source code correlation with u-boot code in CCSv5.5 is widely used by several teams and it just works. Therefore in my experience it is quite usual that u-boot is being built without full symbolic debug information (without the -g option).

    My suspicion is also fueled by the fact the ELF executables you sent are quite small in size. Despite I don't have the RDK for DM385, similar devices such as DM8148 and 8168 get something larger (700kB to 1MB) in size when built with full symbolic debug information.

    You can verify this by checking the option DBGFLAGS of the file config.mk

    One additional detail that impairs debugging is optimization (-O2 is used by default by several u-boot distributions). That would not entirely eliminate the debugging capabilities, though.

    Please double-check this and see if you can get different results.

    Regards,

    Rafael