• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 368 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 temp file linked into device's memory map unexpectedly

Shuyang Zhong
Expert 4505 points

Hi dear CCS team,

A customer is using CC2642, they found that there is an object targeting to a file under C:\Users\<username>\AppData\Local\Temp was in the compiled .map file, which takes ~5k of memory:

The targeted file can be opened with armofd.exe and has the information as below and it looks like some debugging info:

But the customer did not know which option generates this and stop it from being linked into the memory map, it is not used by the customer and they want to remove it to save momery.

Would you please help comment what is this file and how to remove it from the memory map? I attached the entire file as below, thanks.

{50B4475C-2253-46D1-A8FA-D931DA281D52}

simple_peripheral_CC26X2R1_LAUNCHXL_tirtos_ccs.map

Best regards,

Shuyang

  • 0
    TI__Guru**** 243480 points

    I have a partial explanation.

    This happens when you build with --opt_level=4, also called link-time optimization.   For details about link-time optimization, please search the TI ARM compiler manual for the sub-chapter titled Link-Time Optimization.  The large temporary object file comes from link-time optimization.  In the MODULE SUMMARY part of the linker map file, most of the bytes in the large temporary object file are associated with the source files they started in.  However, 5264 bytes of read-write data are not associated with any source file.  We know most of this is from common variables.  But not all of it.  We are still investigating.  Please be patient.

    Shuyang Zhong said:
    it is not used by the customer and they want to remove it to save momery.

    It is all but certain that correct operation of your code requires this read-write data, and so it cannot be removed.

    Thanks and regards,

    -George

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

    Sorry, but our investigation continues.  We are able to see a similar problem in a CCS project we can completely build from source.  We are exploring it on the assumption it is representative of the problem your customer experiences.  Again, please be patient.

    Thanks and regards,

    -George

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

    When an uninitialized global variable is created ...

    Fullscreen
    1
    int uvar;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    ... the compiler does not immediately allocate space for it.  Instead, it creates a common variable.  Think of a common variable as being only partially created.  Later on, when linking, it is determined whether this variable is ever read or written by the program.  If it isn't, it is discarded.  If it is used, then the linker allocates space for it, and otherwise completes the creation of it.  By the time that happens, the association with the source file where the variable is defined is lost.  That is why, in the linker map file, you see entries like ...

    Fullscreen
    1
    2
    3
    200045e0 00000800 (.common:bleTaskStack)
    20004de0 00000800 (.common:gCommCfg)
    200055e0 00000400 (.common:myTaskStack)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Notice how no library or file is associated with these entries.  

    Part of the information in the MODULE SUMMARY part of the linker map file is how much memory is used by the files and libraries in the program.  What happens with the common variables?  For object files (whether from a library or not) that are not built with --opt_level=4, the association with the source file is re-established, and the size of the common variables in a given file contributes to the rw data (last) column.  For object files that are built with --opt_level=4, the association with the link-time optimization temporary object file is the only one which remains.  That is why you see ...

    Fullscreen
    1
    2
    3
    4
    C:\Users\F70401~1\AppData\Local\Temp\
    {50B4475C-2253-46D1-A8FA-D931DA281D52} 0 0 5264
    +--+----------------------------------------+--------+---------+---------+
    Total: 0 0 5264
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If you add up the size of all the common variables in the map file you submitted, it comes to 9603 bytes, more than 5264.  The rest are associated with object files that are not built with --opt_level=4.

    Thanks and regards,

    -George