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.

TI msp430-gcc howto remove unused symbols without removing debug information

Hi,

I am converting a project from using the TI C compiler to the new msp430-gcc (v3.2.3).

I am running into code size problems (region `ROM' overflowed).

The code size can be reduced by not using printf(). When printf() is called in a function which itself is not called it still ends up in the binary however.

Compiling with -ffunction-sections and linking with -Wl,--gc-sections strips the symbols which are not used, and solves the code size problem, but doing this also seems to strip the debug information.
Is there a way to strip the unused functions while still retaining the debug information?


I don't recall this from happening using the 'old' mspgcc, but i'm not 100% sure.

thanks,

Glenn

  • To remove unused functions from the build, they need to be compiled into their own compilation unit. the linker cannot know whether code inside the same compilation unit maybe calls each other through relative links (like multiple functions sharing the same exit code)

    In (properly done) libraries, you'll see that every single function is in its own source file and compiled separately, so the linker can only pick the ones needed and leave the rest.

    The old mspgcc had special compiler and linker switch -ffunction-sections. It forced the compiler to treat each function as a separate independent code unit and the linker could only include those that were actually used. I don't know whether the new MSPGCC supports this too.
  • This used to work with the older gcc compiler (msp430-gcc 4.6.3).  It seems that the latest msp430-elf-gcc strips out the debug in addition to the unused symbols. You might submit a bug on msp430-elf-gcc as it is a regression issue.

    Also, you don't need to put each function into a separate compilation unit. The -ffunction-sections and -fdata-sections flags takes care of putting each function and data variable into their own linker section that can be individually dropped if not used.

    You also might want to check out the new with msp430-elf-gcc -minrt flag.

    -rick


  • Thanks for the reply. I'm not sure where i need to file a bug.
    Should i file a bug on TI bugtracker or on gcc's?

    I tested with -minrt but this seems to increase size in my case.
    The first one is without -minrt, the second is with -minrt :

    msp430-elf-size  apps/phy_test/phy_test 
       text    data     bss     dec     hex filename
      15238     366    1406   17010    4272 apps/phy_test/phy_test
    

    msp430-elf-size  apps/phy_test/phy_test 
       text    data     bss     dec     hex filename
      13906    2004    1422   17332    43b4 apps/phy_test/phy_test
    

  • A good question for a real TI person. I've submitted over in the compiler forum and had things fixed:

    e2e.ti.com/.../343

    -rick
  • could you please update the link in your posting as it does not point to any specific posting anymore.

    Thanks in advance.

  • It seems to have been deleted, maybe they fixed it.
  • Rick Kimball said:
    It seems to have been deleted, maybe they fixed it.

    I wanted to check your posting in the compiler forum first because I ran into a situation where the "--gc-sections" made the linker remove the debug info.

    I'm not sure if it relates to a tight memory situation because in the meantime I've reduced the memory footprint of my code and the debug info is available right now.

    What I can definitely say is that if I select "-ffunction-sections" in addition to "--gc-sections" all debug info vanishes.
    , could you possibly comment on this?


    PS: I' using CCS v6.1.3 [gcc version 5.3.0 (GNUPro 15r1) (Based on: GCC 5.3 GDB 7.7 Binutils 2.25 Newlib 2.2.0) (GCC)]

  • You might try using "-flto" instead. (This requires all interrupt handlers to be marked with "__attribute__((used))".)
  • Hi Friedl,


      Hmm, it is possible that linker garbage collection is the cause of this problem, although I am not sure how...

      The usual problem is that the linker does not remove enough debug information, rather than too much.  (This is because the debug information is held in separate sections to the code, and when the linker removes some unused code, it often forgets to search for and remove the debug information associated with that code).

      If you add --print-gc-sections to the linker command line, you should get some output showing what the linker is throwing away.  Doing this would confirm whether the linker garbage collection really is the problem.

      It does seem unusual though that the linker is stripping needed debug information.  If you can create a small testcase would you mind submitting it to the FSF binutils bug system here: .  The people there might be able to offer some more insight.

    Cheers

      Nick

**Attention** This is a public forum