• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 158 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.

TMS320F2812: New Sections in Linker Output

Ed Sanders
Genius 3830 points
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

  • 0
    TI__Mastermind 34665 points

    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 

  • 0 in reply to Siddharth Deshpande
    Genius 3830 points

    Hi Siddarth,

    Old v4.1.1

    New  v20.2.5 LTS

    Thank you,

    Ed

  • 0 in reply to Ed Sanders
    TI__Mastermind 34665 points

    Hi, 

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

    Best Regards

    Siddharth

  • +1
    TI__Guru**** 244120 points

    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 ...

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    % 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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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 ...

    Fullscreen
    1
    % ofd2000 -g -o=file_info.txt file.out
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 3830 points

    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