• State TI Thinks Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 2947 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/TMS320C6657: C6657

pradeep sabarinadh
Intellectual 290 points
Part Number: TMS320C6657

Tool/software: Code Composer Studio

Hi I have project created in CCS5 with Complier 7.4.1. Of late, I have imported it on to CCS7.4 and Complier 8.2.2.

I am using custom linker. I see large size difference in .const:.string of .const section between CCS5 and CCS7 generated .map files.

Some thing like:

CCS5 .map file 

.const     0    108b7ce0    0001809e

                      xxxxxxx       000005ac     main.obj (.const:.string)

CCS7 .map file 

.const     0    108b7d10    000264de     

                     xxxxxxxx      00000964     main.obj (.const:.string)

Code is exactly the same.

I guess .const:.strings. are the string literals in the code. My main.c file has sprintfs along with UART messages.

Why there is difference in size?

I need UART support even in my production release to monitor the code behavior.

Thank you 

Pradeep

  • 0
    TI__Guru**** 232650 points

    Your situation is very similar to the one discussed in this forum thread.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points
    Hi,
    Thank you for your response.
    I have examined the .asm files generated by the two compliers.
    My code has assert(0) call. When I comment out the assert call in CCS7(Complier8.2.2), both the asm files are almost identical. But, If I build code with assert(0) call in CCS7, the complier generates additional code in asm file.
    Why is that so??
    The additional code I was talking about are the file path of the few files used in the code.
    Some thing like
    $C$SL12: .string "D:",92,"Pradeep",92,"WS_DSP",92,"WS5",92,"DPM",92,"DPM0_Fir"
    .string "mware",92,"src",92,"ABC",92,"ABCD.h",0
    Such code is not there when build with CCS5.

    Any Ideas??

    Regards,
    Pradeep
  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 232650 points

    My guess is that, for some reason, the assert(0) call is seen when building with CCS7 and compiler version 8.2.2, but it is not seen when building with CCS5 and compiler version 7.4.1.  To catch preprocessor problems like this, build with the option --gen_acp_raw and inspect the resulting .rl file.  To understand how this option works, please search for "--gen_preprocessor_listing" in the C6000 compiler manual.  Note that the name of the option is --gen_preprocessor_listing in newer releases, but --gen_acp_raw in older releases.  So, you have to look for the new name in the manual.  But the old option still works in both compiler versions.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 232650 points

    Please let us know what you found after building with --gen_acp_raw and inspecting the .rl file.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points
    Hi George,
    Sorry for the delayed response.
    I have built Code on both CCS5 and CCS7 by setting "--gen_acp_raw" option to one file which has assert(0) call.
    On inspection, assert(0) is listed in both the .rl files generated.

    Both .rl files have
    #define COM_ASSERT_LOG(expression, code) \
    N { \
    N if ((expression) == 0) \
    N { \
    N COM_ERR_LOG((code)); \
    N memcpy(com_exceptionInfo.assertionFilename, __FILE__, min(sizeof(com_exceptionInfo.assertionFilename), sizeof(__FILE__))); \
    N com_exceptionInfo.assertionFilename[sizeof(com_exceptionInfo.assertionFilename)-1] = '\0'; \
    N com_exceptionInfo.assertionLineNo = __LINE__; \
    N COM_UartWrite((char *)com_exceptionInfo.assertionFilename); \
    N sprintf(logbuf, " Line = %d\r\n",com_exceptionInfo.assertionLineNo); \
    N COM_UartWrite(logbuf); \
    N assert(0); \ //commenting this built without errors in CCS7
    N } \
    N }

    Regards,
    Pradeep
  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 232650 points

    pradeep sabarinadh said:
    Both .rl files have
    #define COM_ASSERT_LOG(expression, code) \

    That is not conclusive.  It just means that both builds have a macro named COM_ASSERT_LOG that, among other things, calls assert.  Find a place where COM_ASSERT_LOG is invoked.  Does it expand to the same thing in both builds?  I suspect it doesn't.  

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points
    Hi George,
    I modified my code to get COM_ASSERT_LOG called.
    Below are the pertaining lines in respective '.rl' files
    CCS5:
    { if ((0) == 0) { COM_ErrLog((1));; memcpy(com_exceptionInfo . assertionFilename, "../main.c", ((sizeof(com_exceptionInfo . assertionFilename))<(sizeof("../main.c"))?(sizeof(com_exceptionInfo . assertionFilename)):(sizeof("../main.c")))); com_exceptionInfo . assertionFilename[sizeof(com_exceptionInfo . assertionFilename)-1] = '\0'; com_exceptionInfo . assertionLineNo = 112; COM_UartWrite((char *)com_exceptionInfo . assertionFilename); sprintf(logbuf, " Line = %d\r\n",com_exceptionInfo . assertionLineNo); COM_UartWrite(logbuf); _assert((0) != 0, "Assertion failed, (" "0" "), file " "../main.c" ", line " "112" "\n"); } };

    CCS7:
    { if ((0) == 0) { COM_ErrLog((1));; memcpy(com_exceptionInfo . assertionFilename, "../main.c", ((sizeof(com_exceptionInfo . assertionFilename))<(sizeof("../main.c"))?(sizeof(com_exceptionInfo . assertionFilename)):(sizeof("../main.c")))); com_exceptionInfo . assertionFilename[sizeof(com_exceptionInfo . assertionFilename)-1] = '\0'; com_exceptionInfo . assertionLineNo = 110; COM_UartWrite((char *)com_exceptionInfo . assertionFilename); sprintf(logbuf, " Line = %d\r\n",com_exceptionInfo . assertionLineNo); COM_UartWrite(logbuf); _assert((0) != 0, "Assertion failed, (" "0" "), file " "../main.c" ", line " "110" "\n"); } };

    Both yield same listings

    Regards,
    Pradeep
  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 232650 points

    pradeep sabarinadh said:
    I modified my code to get COM_ASSERT_LOG called.

    I don't understand why you did that.  If one build is calling COM_ASSERT_LOG, and the other isn't, then that explains the difference in the size of the .const:.string section.

    pradeep sabarinadh said:
    Both yield same listings

    Does the difference in .const:.string remain?  Or does it go away?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points
    Hi,

    <<If one build is calling COM_ASSERT_LOG, and the other isn't, then that explains the difference in the size of the .const:.string section.>>
    I did not understand how you arrived at this.

    <<Both yield same listings>>
    By this I meant that .rt file yields same listing for both the builds.

    <<Does the difference in .const:.string remain? Or does it go away?>>

    There are differences.

    CCS5 .map shows
    length attributes
    ----------- --------------
    00000372 main.obj (.const:.string)

    CCS7 .map shows
    000009c0 main.obj (.const:.string)

    Regards,
    Pradeep
  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 232650 points

    pradeep sabarinadh said:
    <<If one build is calling COM_ASSERT_LOG, and the other isn't, then that explains the difference in the size of the .const:.string section.>>
    I did not understand how you arrived at this.

    An invocation of COM_ASSERT_LOG causes some strings to be added to .const:.string.  So, if one build is calling COM_ASSERT_LOG, and the other isn't, you have to expect a difference in the constant strings.

    pradeep sabarinadh said:
    <<Both yield same listings>>
    By this I meant that .rt file yields same listing for both the builds.

    <<Does the difference in .const:.string remain? Or does it go away?>>

    There are differences.

    I cannot explain that.  Please send in the following.  For main.c from each CCS project, create a test case as described in the article How to Submit a Compiler Test Case.  The file names will be the same, so do something like add _ccs5 to one, and _ccs7 to the other.  I plan to use those two test cases to reproduce the result where the .const:.string section is of a very different length.

    Because I suspect something has gone wrong during preprocessing ... While creating those two test cases, also use the option --gen_acp_raw to create the .rl file for each project, and send those in as well.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points

    New folder.7z

    I have generated two .pp files from CCS5.3 with complier 7.4.1 and CCS7.4 with complier 8.2.2

    I am forbidden from sharing the .rl files as there are lot of logic related comments in the code. Is there a way to remove those just like the one for .pp files.

    Regards,

    Pradeep

  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 232650 points

    Thank you for sending in the files.  They are quite different.  I'll detail some of the differences I found.

    Because it makes things easier, I copied the preprocessed files over to files named m5.c (the CCSv5 one) and m7.c (the CCSv7 one).  You didn't include the build options you use, so I guessed.  While the options I chose are certainly not a match, I am confident they are close enough for useful comparison.  I built each file, with the corresponding compiler version, like this ...

    % cl6x -mv6600 -o3 -s -pds=179 m5.c
% cl6x -mv6600 -o3 -s -pds=179 m7.c

    Explanation of the options

    • -mv6600 - Build for the C6600 family of devices
    • -o3 - The highest level of optimization.  At this level, function inlining occurs automatically.
    • -s - Adds compiler generated comments to the assembly, to make it easier to understand.  Also causes the .asm file to remain, and not get deleted.
    • -pds=179 - This suppresses a warning that is common when compiling preprocessed files.  The warning is worth ignoring here.

    So, inspect the assembly files, and find the .string.:.const section.  Here is one entry from m7.asm ...

    $C$SL5:	.string	"Assertion failed, (0), file ../main.c, line 376",10,0

    This string is what you get when you use the assert macro from assert.h.  The macro COM_ERR_LOG invokes the assert macro.  Based on this pattern, you can count how many times the assert macro is used in each file.  I used this Unix-like command to do it ...

    $ grep 'string.*Assertion failed' m5.asm | wc -l
12

    That grep command finds any line that has "string something Assertion failed" on it, and wc -l counts them.  m5.asm has 12.  Do the same thing for m7.asm.

    $ grep 'string.*Assertion failed' m7.asm | wc -l
19

    It has 7 more.  Inspect them, and you'll see that this is typical of ones that are in m7.asm, and not in m5.asm.

    $C$SL21:
        .string	"Assertion failed, (0), file D:",92,"Pradeep",92,"WS_DSP",92
	.string	"WS5",92,"DPM",92,"DPM0_Firmware",92,"src",92,"IFFEI",92,"IF"
	.string	"FEI_SrioSetDstfifoRaw.h, line 102",10,0

    (I reformatted it slightly.)  These three lines form one continuous string, that ends with newline (10), and NULL (0).  The value 92 is the ASCII code for the character backslash (\).  Note the filename after the last 92 is IFFEI_SrioSetDstfifoRaw.h.  That filename is broken up across two lines.  Note m7.asm has 7 asserts like this for files that are named IFFEI_something.  These are the 7 asserts that m7.asm has that m5.asm does not.  

    I also used ofd6x to see the names of the functions that are in each object file.  Like this ...

    $ ofd6x --func_info m5.obj
"APMAIN_AtexitHandler","m5.c",0x00000dd8,0x00000dec,20
"APMAIN_CommonInitialize","m5.c",0x00000000,0x0000004c,76
"APMAIN_Exit","m5.c",0x00000da8,0x00000dd8,48
"APMAIN_FrameworkFinalize","m5.c",0x00000da4,0x00000da8,4
"APMAIN_FrameworkInitialize","m5.c",0x0000004c,0x00000240,500
"APMAIN_QmssFinalize","m5.c",0x00000da0,0x00000da4,4
"APMAIN_QmssInitialize","m5.c",0x00000240,0x00000654,1044
"main","m5.c",0x00000654,0x00000da0,1868

    If you do the same thing for m7.obj, you will see it has these functions, and many more.

    I don't know the source of all these differences.  One guess ... The new build uses a later version of SYS/BIOS, and the SYS/BIOS header files are quite different.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points
    Hi George,
    Thank you for your analysis.
    Yeah I too observed that the file name get broken in two lines when build on CCS7, 'Assertion failed' count differs between the two and few others.
    The sys/bios version used is same for both CCS5 and CCS7.
    So, what's next??
    Is code modifications the only option ?? I wonder why migrating to latest IDE and tools requires code modifications.
    I need to send TI's response to my team and we need to take call for the way forward.

    Regards,
    Pradeep
  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 159715 points

    Pradeep,

    You mentioned that the SYS/BIOS version is the same.  Did you also use the same XDCTools version?

    By default CCSv7 is going to use a newer version of the XDCTools.  You can go into CCSv5.5 and check the version of XDCTools that is being used by the project.

    Then go back to CCSv7 and you can tell CCS where that version is by going to Window -> Preferences and adding the path at the location below.  You specify the location at the top of the dialog and then CCS shows what it has found at the bottom:

    Once CCS is aware of the version you can then go into the properties of the project and tell CCS to use that version for the project.  The same dialog will enable you to confirm the SYS/BIOS version being used:

    I would also see if the project is using any other software products like the NDK and confirm that the versions are the same.

    Regards,

    John

  • 0 in reply to JohnS
    Intellectual 290 points

    Hi,

    I am using same XDC tool version for both the builds. In fact I just copy pasted the all tools after installing CCS5 and CCS7 at respective directories.

    Please have a look at the images posted.

    Regards,

    Pradeep

  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 232650 points

    Please try this experiment.  In the CCSv7.4 project, change the compiler version back to the one you used in CCSv5, which is compiler version 7.4.x.  See this article to learn the details of how to do that.  Let us know what happens.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points
    Hi George,
    I tried your experiment.
    CCS7.4 with complier 7.4.1 and CCS5.3 with complier 8.2.2
    On CCS7 with complier 7.4.1, I could not successfully build my original code base.
    Where as on CCS5.3 with complier 8.2.2,
    I could build core 1 code without any changes, while core 0 code builds only when assert(0) code is commented.
    Surprisingly, assert(0) is used in core 1 code too.

    Regards,
    Pradeep
  • 0 in reply to pradeep sabarinadh
    TI__Guru**** 232650 points

    pradeep sabarinadh said:
    On CCS7 with complier 7.4.1, I could not successfully build my original code base.

    That's unfortunate.  I thought this would show that, even when using the older compiler, the size of the .const:.string section is very different.  

    Did you reproduce the results I describe in detail in my post dated March 1?  This post shows that the compiler sees very different code between the builds.  There is no other way to explain 7 more invocations of the assert macro, or the very different number of functions.  To the extent that different code is caused by using different versions of TI software packages like XDC or SYS/BIOS  ... The post by JohnS dated March 2 shows you how to change the version of those software packages back to what is used in the older build.  That is everything TI controls.  The rest of the difference must be explained by you.

    Thanks and regards,

    -George