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.

TMS320F2812: New Sections in Linker Output

Part Number: TMS320F2812


Greetings,

                I am porting older code to the newer tools, and the resulting abs file contains sections which are not present when using the older tools.  Specifically, the new sections are:

.debug_aranges

.debug_pubnames

.debug_pubtypes

$build.attributes

                I have been trying to find an explanation of these, but have been unsuccessful in finding them in any of the documents I am currently aware of.  Where should I be looking?

Thank you,

Ed

  • Hi 

    Please let us know the versions of the tools you were using earlier and which one are you trying to migrate to.

    Best Regards

    Siddharth 

  • Hi Siddarth,

    Old v4.1.1

    New  v20.2.5 LTS

    Thank you,

    Ed

  • Hi, 

    I will forward the query to the compiler team to clarify.

    Best Regards

    Siddharth

  • All of these sections are not directly related to memory on the target system.  They contain information about the executable file.  The sections that start with the name .debug contain information for a debugger, such as Code Composer Studio.  The section $build.attributes contains information about how the file is built, such as the CPU selected, compiler options, memory model, etc.  The linker uses build attributes to check on whether the files and libraries are compatible. 

    The object file display utility ofd2000 can help you understand the content of these sections.  It is documented in the C28x assembly tools manual.  Here is an example ...

    % ofd2000 --obj_display=none,sections file.out
    
    OBJECT FILE:  file.out
    
     Section Information
    
        id name                      page load addr  run addr     size align alloc
        -- ----                      ---- ---------  --------     ---- ----- -----
         1 $build.attributes            0 0x00000000 0x00000000   0x2a     1   N
         2 .text                        0 0x00000040 0x00000040  0xab9     1   Y
         3 .data                        0 0x00000040 0x00000040      0     1   Y
         4 .bss                         1 0x00000000 0x00000000      0     1   Y
         5 .cinit                       0 0x00000af9 0x00000af9   0x79     1   Y
         6 .pinit                       0 0x00000000 0x00000000      0     2   N
         7 .stack                       1 0x00000400 0x00000400  0x400     2   Y
         8 .esysmem                     1 0x00000000 0x00000000  0x400     2   Y
         9 .ppdata                      0 0x00000000 0x00000000      0     1   N
        10 .debug_info                  0 0x00000000 0x00000000 0x9ddf     1   N
        11 .econst                      0 0x00000b72 0x00000b72   0x10     2   Y
        12 .debug_frame                 0 0x00000000 0x00000000  0x8e0     4   N
        13 .debug_line                  0 0x00000000 0x00000000 0x1619     1   N
        14 .reset                       0 0x00000b82 0x00000b82    0x2     2   Y
        15 .ebss                        1 0x00000800 0x00000800  0x1b0     2   Y
        16 .cio                         1 0x000009c0 0x000009c0  0x120     1   Y
        17 .debug_abbrev                0 0x00000000 0x00000000  0x33e     1   N
        18 .debug_aranges               0 0x00000000 0x00000000  0x5e0     1   N
        19 .debug_pubnames              0 0x00000000 0x00000000  0x749     1   N
        20 .debug_pubtypes              0 0x00000000 0x00000000  0x506     1   N

    The output is limited to information about sections.  Note the column titled alloc.  For sections where this entry is N, it is a section that is empty, or it does not directly affect execution.  

    To get a better sense of what these sections contain, run a command similar to ...

    % ofd2000 -g -o=file_info.txt file.out

    ... then inspect the text file file_info.txt.

    Thanks and regards,

    -George

  • I had a feeling that was the case, but needed to hear it from the authority.

    I ran ofd2000 on an out file, and can see that it provides a ton of information which I will be using to work on a different issue I am having.

    Thank you George,

    Ed