• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 85 subscribers
  • Views 772 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.

Compiler/C2000-CGT: Inconsistent sizes in linker map file

Thomas Dedler
Intellectual 270 points
Part Number: C2000-CGT


Tool/software: TI C/C++ Compiler

Hello,

I use the TI CGT C2000 18.12.0 toolchain and parse the map files with a script to get the size of the generated code.

Now I noticed that the size of the memory area at the beginning of the map file is sometimes smaller than the size of the actual executable. I looked at several map files in different application, and the delta was often between 1 and 6 words. However, when I checked the more detailed section description in the map file, the size was correct and consistent with the generated executable.

Here an example for one of the affected memory areas:

         name           origin    length      used     unused   attr   fill
---------------------- --------  ---------  --------  --------  ----  --------

  EXER_TEXT            00318010   00007ff0  000045f5  000039fb  R  X

 

When I calculate the end address from this info, I get 0x00318010 + 0x000045f5 - 1 = 0x31C604

 

Now when I look at the last section in EXER_TEXT, I find the following in the map file:

.switch    0    0031c4da    0000012e    

                  0031c4da    000000c8     Exer.obj (.switch:_Exer_xx_Parser)

                  0031c5a2    00000032     Exer.obj (.switch:_Exer_yy_Parser)

                  0031c5d4    0000001c     MemoryAccess.obj (.switch:_MemoryAccess_Parser)

                  0031c5f0    00000018     Exer.obj (.switch:_Exer_Parser)

When I calculate the end address from this info, I get 0x0031c5f0 + 0x00000018 - 1 = 0x31c607 (which is also the end address in memory when I checked it with the debugger)

 

After some try and error I think I found a workaround for it. Previously, the sections in the linker command file were just listed in a SECTION. Now when I enclose all section in EXER_TEXT in a GROUP block to allocate them contiguously in memory, the size in the map file is correct.

 

My questions are:

- are these inconsistent sizes a known bug of the linker?

- when I use a GROUP in the linker command file, does this really guarantee that the memory size in the map file is correct, or did it just accidentally work in the given project and may occur again in the future?

 

Regards,

Thomas

  • 0
    TI__Guru**** 251060 points

    Thank you for notifying us of this problem.  I can reproduce the same behavior.  I filed the entry EXT_EP-9786 to have this investigated.  You are welcome to follow it with the link below in my signature.

    Thomas Dedler said:
    I use the TI CGT C2000 18.12.0 toolchain and parse the map files with a script to get the size of the generated code.

    Parsing the map file is not the best idea.  The map file is intended for users to read, not scripts.  The map file may have minor changes between releases.  Such changes often are unnoticed by users, but can cause problems for a script.

    One alternative ... Instead of processing the map file, process the XML equivalent produced the option --xml_link_info=filename.  Please search the C28x assembly tools manual for that option.  For example Perl scripts which process this file, please install the cg_xml package.

    Another alternative ... In later versions of the C2000 compiler, the map file contains a summary on memory usage titled MODULE SUMMARY.  This summary breaks down memory usage a few different ways.

    Thanks and regards,

    -George

  • 0
    TI__Guru* 84285 points

    There is most likely an unused gap between output sections due to alignment or blocking.  Check each section to see whether its origin plus its length is exactly the origin of the next section.  If not, you've found a gap.  These gaps aren't counted toward words used.

  • 0 in reply to George Mock
    Intellectual 270 points

    George Mock said:

    One alternative ... Instead of processing the map file, process the XML equivalent produced the option --xml_link_info=filename.  Please search the C28x assembly tools manual for that option.  For example Perl scripts which process this file, please install the cg_xml package.

    Thanks for the hint, this sounds reasonable. We will regard it for future projects. But because the version is already fixed for the current project (and with it the map file format), we would for now prefer to keep the scripts as they are. Of course, only if the workaround with the section group is really reliable.

    @Archaeologist
    Yes, I can confirm this at least for one map file. The sum of all gaps between output sections is equal to the deviation of the memory area size from the real used size.
    There are still gaps when I put the output sections in a group. However, then the overall used memory size is correct. Looks like the linker calculates it different when using a group?

  • 0 in reply to Thomas Dedler
    TI__Guru* 84285 points

    Well, the situation is a bit different when it's in a group, so yes, the gaps are counted differently.

    Consider the non-group situation.  Yes, there are small gaps between some sections, but it's not necessarily wasted space.  It's possible for there to be tiny sections that would fit there, so it's space that is still available, so it's counted as "unused."

    When using groups, you control which sections end up in the group, and the group occupies its entire memory footprint.  Once the group is laid out, there is no chance for tiny sections to be added, so those gaps aren't available, so they are counted as "used."  (This is off the top of my head; I haven't studied the source code to confirm this.)