Hello everyone,We have detected an interesting case when reading debug information for our tools for files
that have been built with C6000 compiler. Besides the specific usage of DIE elements with name CIE_RETA that have been explained in TI documentation we have found that name attribute in DIEs containing CIE_RETA have one extra byte in length.It was possible to detect this issue by debugging inside the parser and comparing the parsing
steps with the output produced by ofd6x.exe1. Output from ofd6x.exe: 00016a64 27 DW_TAG_TI_assign_register00016a65 DW_AT_location DW_OP_regx 12700016a68 DW_AT_name DETR <- the size is OK (6d - 68=5 bytes=4 chars + term)00016a6d 27 DW_TAG_TI_assign_register00016a6e DW_AT_location DW_OP_regx 22800016a72 DW_AT_name CIE_RETA <- the size is bigger (7c-72=10 bytes>8 chars + term)!00016a7c 28 DW_TAG_pointer_type00016a7d DW_AT_address_class DW_ADDR_TI_PTR32 The fact that this string attribute (it is possible to confirm it is a string because the attribute type
is DW_FORM_string or 0x08) has different size than it should have makes our parser read
incorrect abbrev. identifier (because of the wrong offset) and terminate the parsing of DIEs
for current compilation unit.
Could you please help me with a link to a document that describes this behavior
or with additional information what would be the preferred way of handling such cases.
Thank you very much in advance for your help,
I am using v7.3.1 of the C6000 compiler tools. And I cannot reproduce what you describe. So, one possible solution is to upgrade your compiler to v7.3.x. If that isn't possible for some reason, please submit a test case. The last part of the forum usage guidelines gives the details on doing that.
Thanks and regards,
TI C/C++ Compiler Forum ModeratorPlease click Verify Answer on the best reply to your question.The Compiler Wiki answers most common questions.Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.
Thank you very much for your reply. As this is a project of our customer I am not able to upload it directly without a permission. However I will try to obtain one and provide you with an example.
As far as I'm aware the compiler version that have been used for building this out file is built with compiler version 220.127.116.11:
File Name: broken.out Format: TI-COFF Version 2 File Type: executable file Time Stamp: Fri Feb 24 18:14:30 2012 Machine: TI C6x Machine Endian: little endian Entry Point: 0xc01277c0 Vendor: Texas Instruments, Inc. Vendor Version: 6001 Number of Sections: 29 File Length: 36663922 TI-COFF f_flags: 0x00000193 TI-COFF f_flag: F_RELFLG (relocation info stripped) CPU Generation: 0x9 Control Data Endian: little endian Start of .text Section: 0xc0000020 Start of .data Section: 0xc0000010 Size of .text Section: 1268224 Size of .data Section: 0 Size of .bss Section: 6626
For a number of reason this customer wants to stick this compiler version, so we're trying to find out why exactly this situation happens.
What I can provide as an additional information is that this special case happened when building C++ application which also has stlport library.
Since we have tested with other projects it was possible to observe similar size behavior of CIE_RETA, but in our other projects the CIE_RETA tag
was always put at the end of the compilation unit, and in this case having one extra byte and reading zero abbrev id is actually correct and does not have
side effects on our parsing:
00013569 56 DW_TAG_TI_assign_register 0001356a DW_AT_location DW_OP_regx 127 0001356d DW_AT_name DETR 00013572 56 DW_TAG_TI_assign_register 00013573 DW_AT_location DW_OP_regx 228 00013577 DW_AT_name CIE_RETA ---------------------------- DIE Table at Offset 00013581 ---------------------------- Length: 55403 Version: 2 .debug_abbrev Offset: 00000823 Address Size: 4
Thank you very much once again for your information,
I have not exactly reproduced your issue. But I did experiment and find that, for a simple test case, the v7.3.4 compiler always encodes the CIE_RETA register name in 9 bytes, and the v6.1.20 compiler appears to encode it in 10 bytes. So, I filed the entry SDSCM00043576 in the SDOWP system. In it, I describe this difference in detail and ask for an explanation. Perhaps it is a bug that has been fixed. I don't know. But I think this is the best way to find out. You can track this issue with SDOWP link below in my signature.
BTW, I used v6.1.20 and not v6.1.19 because I wanted to use the latest version along that release stream. Release v6.1.20 differs from v6.1.19 only in bug fixes.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.