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.

28xx compiler: manual override of --gen_func_subsections in the source code

I recently started using --gen_func_subsections to allow the linker to leave out unreferenced functions.

Is there any way in source code to override this behavior for a particular function, either by:

(a) forcing a particular function to be placed into exactly the section I specify, and *not* a subsection as seems to be the case with --gen_func_subsections

(b) somehow telling the compiler to mark a function as needs-to-be-included in the output executable, even though it never gets called?

The only way I can think of is to store the address of the function in a static dummy variable, but I'm not sure that will work.

  • Jason R Sachs said:
    (a) forcing a particular function to be placed into exactly the section I specify, and *not* a subsection as seems to be the case with --gen_func_subsections

    Use the CODE_SECTION pragma.

    Jason R Sachs said:
    (b) somehow telling the compiler to mark a function as needs-to-be-included in the output executable, even though it never gets called?

    Use the RETAIN pragma.

    Both pragmas are documented in the C28x Compiler User's Guide.

    Thanks and regards,

    -George

  • Georgem said:
    Use the RETAIN pragma.

    Ah, I missed that one. Thanks! (and its alternative, CLINK, looks useful too.)

     

    Georgem said:
    Use the CODE_SECTION pragma.

    --gen_func_subsections seems to append a subsection of the function name no matter what. For example, I have this in the code:

    #pragma CODE_SECTION("fast:LRTM");
    void LowRateTaskManager::step()

    but it shows up in section fast:LRTM:_step__18LowRateTaskManagerFv rather than fast:LRTM.


  • Georgem said:
    Use the RETAIN pragma.

    Hmm. I can't seem to get it to work.

    What's the syntax for C++?

    #pragma RETAIN("foo")
    void foo()
    {
      // dummy function

    }

    or is it

    #pragma RETAIN(foo)
    void foo()
    {
      // dummy function

    }


    I can't seem to get either to work.

     

  • C++ pragmas attach by position not by name.  Use the following:

    #pragma RETAIN
    void foo()
    {
        // dummy function
    }

     

  • Paul Knueven said:

    C++ pragmas attach by position not by name.  Use the following:

    #pragma RETAIN
    void foo()
    {
        // dummy function
    }

    That may be the syntax, but it doesn't appear to work properly.

    After running around in circles, I finally created a test file unused_funcs.cpp:

    void nullfunc1()
    {
    }

    #pragma RETAIN
    void nullfunc2()
    {
    }

    void somefunc()
    {
    }

    where somefunc() gets used by main(), but the other functions do not. I compiled it with cl2000 5.2.6 with these flags:

    --compile_only --keep_asm --asm_directory=build --obj_directory=build --opt_level=1 -g -v=28 -ml --gen_func_subsections

    When I link with lnk2000 5.2.6 with these flags:

    --rom_model --generate_dead_funcs_list

    then nullfunc1 and nullfunc2 show up in the dead_funcs.xml file and do not show up in the .out file.

  • The retain pragma is not supported in the C2000 compiler until release v6.0.0.  When I try your test case with v5.2.6, I get a diagnostic about pragma not recognized.

    The retain pragma does not work in any version of the C2000 compiler.  I filed SDSCM00042114 in the SDOWP system to get that fixed.

    The documentation of the retain pragma is incorrect.  In C++, it does not take any parameters.  It is applied to the next function in the same manner as the CODE_SECTION pragma.  I filed SDSCM00042116 in the SDOWP system to have the book updated.  

    You can track these issues with the SDOWP link in my sig below.

    Thanks and regards,

    -George

  • Hmm. I'm now using rev 6.0.2 of the compiler (from CCS 5.1.0) and the issue still hasn't been fixed. Any progress? I checked SDSCM00042114 but there's not really any information and I can't tell what the status is. (not sure what "Accepted" means -- fix accepted, or issue accepted needing a fix?)

  • Jason R Sachs said:
    not sure what "Accepted" means -- fix accepted, or issue accepted needing a fix?

    The latter