• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 216 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.

TMS320F28388D: Inconsistencies in Code Coverage Analysis Results (CSV Files)

Pierre Bouchet1
Expert 2595 points

Part Number: TMS320F28388D

Tool/software:

Hello,

I am working with CCS v10.4 and compiling a C project with the CGT 20.2.3.LTS compiler.

  • I compile the CCS project with the --gen_profile_info option to generate a pprofout.pdat file.
  • I process this file along with the executable (.out) using pdd2000.exe utility to generate a pprofout.prf file
  • I rebuild the CCS project with --analyze=codecov, --analyze_only and passing pprofout.prf to --use_profile_info, which generates a set of CSV files containing coverage information.

I notice two issues with the output of the analysis in the CSV files:

  1. In every CSV file the rows are duplicated (this is similar to  CC1312R: Code Coverage Analysis duplicated csv data). No big deal, I can live with that.
  2. In one of the CSV files I notice that none of the rows have a nonzero frequency count. It is expected since none of the functions in the corresponding translation unit are executed by the program.
    1. But then why this file specifically? There are other source files that don't contain any code that is called in this specific build, and yet the tool does not generate any CSV file for them!
    2. Furthermore, I can see in the link information file that none of the functions defined in that translation unit are actually retained at link time. None of them end up in the executable object code.

I investigated the link information file further and noticed that oddly there are a few sections listed from the object file of that translation unit, but none of them are directly my code. After some digging, it turns out that if any part of my source code calls one of the following functions (there might be others) : __isnanf, __isinff - then the Linker considers them to be part of a translation unit which is not actually the one where they are called from.

Is this a bug?

Best Regards,

Pierre

  • 0
    TI__Genius 9161 points

    Hi,

    Let me loop the experts for more information.

    Thanks

    Aswin

  • 0 in reply to Aswin P
    TI__Guru**** 252710 points

    Please follow the steps described in the article Code Coverage with TI Compilers.  Be sure the section .ppdata is allocated to the same kind of memory as the stack or the section .bss.  Make sure your system can support C I/O operations like fwrite.  Does that help?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 2595 points

    Hi George,

    I am afraid that doesn't help because your suggestions do not address the issue I encountered.

    My message literally starts by listing the steps I successfully followed and stating that my problem is with the contents of the CSV files that are populated in the process.

    When I was writing the message I added my findings as I went which may have created some confusion. The part where I am actually stuck is the last sentence:

    After some digging, it turns out that if any part of my source code calls one of the following functions (there might be others) : __isnanf, __isinff - then the Linker considers them to be part of a translation unit which is not actually the one where they are called from.

  • 0 in reply to Pierre Bouchet1
    TI__Guru**** 252710 points

    Are you building with the compiler options --abi=eabi and --opt_level=0 or higher?  If not, does it get better when you use them?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 2595 points

    Hi George,

    I am indeed building with --abi=eabi but --opt_level is off, not 0.

    If I turn on --opt_level=0 the built-in functions __isnanf, __isinff, etc., no longer appear in the .map file generated by the linker. In addition, looking at the map file I also notice that the translation unit to which the Linker considers them to belong no longer has a generated .ppdata.

    Is this behavior known? The released software will still use -Ooff, so I guess I won't be enabling -O0 permanently. In any case, having just an extra CSV file generated by pdd2000 is not a problem.

  • +1 in reply to Pierre Bouchet1
    TI__Guru**** 252710 points
    Pierre Bouchet1 said:
    If I turn on --opt_level=0 the built-in functions __isnanf, __isinff, etc., no longer appear in the .map file generated by the linker. In addition, looking at the map file I also notice that the translation unit to which the Linker considers them to belong no longer has a generated .ppdata.

    Suppose you have C code that contains this statement ...

        if (isnan(float_variable))

    When built with no optimization, the compiler generates a static copy of a function named ___isnanf, and calls it.  This is repeated in each source file where this occurs.  

    When built with --opt_level=0 or higher, the instructions to check for NAN are generated in place, and no function is called.  

    I apologize for taking so long to give an accurate answer.  I focused on the wrong thing.

    Thanks and regards,

    -George