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

[CGTv8.1, OpenMP for KeystoneI] tbss and tdata sections

Naoki Kawada
Guru 19890 points

Hi,

When I build my OpenMP application code, some warnings are raised on CCS console:

warning #10247-D: creating output section ".tdata" without a SECTIONS specification
warning #10247-D: creating output section ".tbss" without a SECTIONS specification

First of all, I'm not completely sure what are these sections, but anyway I tried to put them into some memory as below, but the build system did not handle them correctly -- The build system looks ignoring the placement for these sections. The warnings are still existing here. 

SECTIONS {
	.tdata > L2SRAM //Or, DDR3
	.tbss > L2SRAM //Or, DDR3
}

I'm reading compiler user guide, especially TLS related explanations, for example, chapter 7 Thread-Local Storage Allocation and Addressing.
But still I can't understand what is intended by these sections in OpenMP runtime.

Could you please give me some insight for this ? What should I do for the warnings ?

Best Regards,
Naoki

 

  • 0
    TI__Intellectual 2275 points

    Hello Naoki,

    First, the .tdata and .tbss are compiler generated sections in which thread-private data objects are defined. These are also commonly referred to as thread-local storage or TLS data objects. The .tdata input sections generated by the compiler contain TLS data objects that are initialized and the .tbss input sections contain TLS data objects that are uninitialized.

    Second, it is important that the .tdata and .tbss sections for an application be allocated into a single contiguous block. To get rid of the linker warning and ensure that the .tdata and .tbss sections are properly collected and allocated at link time, you'll want to add the following to your linker command file:

    SECTIONS

    {

       ...

       .TI.tls: > L2SRAM

       ...

    }

    This will cause the linker to collect all .tdata input sections followed by all .tbss input sections into a single TLS block, allocated in the L2SRAM memory area. This will serve as the TLS block for the main thread.

    Do you have a multithreaded application that requires support of TLS in the C/C++ runtime library and the underlying runtime operating system?

    If so, there are a few more details you'll need to account for.

    Thanks and Regards,

    Todd Snider

    Compiler Support Team

    Texas Instruments Incorporated

  • 0 in reply to Todd Snider
    Guru 19890 points

    Hello Todd,

    Thank you for your help. As your suggestion,  .TI.tls: > L2SRAM statement in linker command file makes these sections go into L2SRAM area.
    However, the warning itself is still existing. In the compiler user guide, I found the following statements:

    7.4.2.3.2 Main Thread’s TLS Allocation
    Users can specify the allocation for the main thread's TLS block using:
    .TI.tls > RAM
    This uninitialized output section is initialized using the __TI_tls_init_table copy table at boot time. Users
    cannot specify the section specifier for this section.

    I'm assuming the uninitialized output sections are actually .tbss and .tdata and these allocations are strictly under control of .TI.tls section allocation. And we can't specify the section mapping directly in *.cmd file such like the following :

    .tdata :> L2SRAM // This is not allowed!
    .tbss :> L2SRAM // This is not allowed!

    So the warning is still expected and we can ignore them. Is my understanding correct ?

    Todd Snider said:

    Do you have a multithreaded application that requires support of TLS in the C/C++ runtime library and the underlying runtime operating system?

    If so, there are a few more details you'll need to account for.

    In fact, I'm not 100% sure what you mentioned, but trying to answer your question and some background. My application is very simple -- It is running on C6678 EVM and an algorithm in main function by using OpenMP runtime. The algorithm is executed in parallel among c66x cores by using 'omp for' pragma. This application code is intended to provide my customers as an example in order to promote your OpenMP solution on keystone devices. 

    My application code does not intentionally use these sections(.tbss and .tdata). It seems OpenMP runtime uses these sections.
    Because these sections are related to TLS, I'm wondering where I should allocate these sections to existing memories.
    Basically, I have the following memories in the system :

    - L2SRAM (local address)
    - DDR3
    - MSMC

    Because L2SRAM is being defined with local address, mapping sections to L2SRAM means that each core(0-7) regards them as 'private'. On the other hand, mapping sections to DDR3/MSMC means that each core(0-7) regards them as 'shared'.
    What I don't really understand is whether the sections (.tbss and .tdata) can be regarded as 'shared' among the cores. If not, I need to map them to L2SRAM by following your suggestion. Please note my application works correctly in both case.  Any suggestions for this ?

    Best Regards,
    Naoki

  • 0 in reply to Naoki Kawada
    TI__Intellectual 2275 points

    Hi Naoki,

    You wrote:

    " As your suggestion,  .TI.tls: > L2SRAM statement in linker command file makes these sections go into L2SRAM area.

    However, the warning itself is still existing."

    "I'm assuming the uninitialized output sections are actually .tbss and .tdata and these allocations are strictly under control of .TI.tls section allocation. And we can't specify the section mapping directly in *.cmd file such like the following :

    .tdata :> L2SRAM // This is not allowed!

    .tbss :> L2SRAM // This is not allowed!

    So the warning is still expected and we can ignore them. Is my understanding correct ?"

    I was able to reproduce the behavior you are seeing if I have the '-w' linker option turned on. Your interpretation that the .tdata and .tbss sections are under the control of the .TI.tls section is correct. When ".TI.tls: > L2SRAM" is specified in the linker command file, the linker will behave as if you had written:

      GROUP ".TI.tls"

      {

         .tdata: { *(.tdata) }

         .tbss: { *(.tbss) }

      } > L2SRAM

    I believe the linker is being misleading by generating warnings for the creation of .tdata and .tbss when ".TI.tls: > L2SRAM" is used in the linker command file. I have submitted a defect report against the linker for this issue (SDSCM00052804) to avoid generating warnings about .tdata and .tbss when a legal ".TI.tls" specification is present in the linker command file.

    You wrote:

    "My application code does not intentionally use these sections(.tbss and .tdata). It seems OpenMP runtime uses these sections.

    Because these sections are related to TLS, I'm wondering where I should allocate these sections to existing memories.

    Basically, I have the following memories in the system :

    - L2SRAM (local address)

    - DDR3

    - MSMC

    Because L2SRAM is being defined with local address, mapping sections to L2SRAM means that each core(0-7) regards them as 'private'. On the other hand, mapping sections to DDR3/MSMC means that each core(0-7) regards them as 'shared'.

    What I don't really understand is whether the sections (.tbss and .tdata) can be regarded as 'shared' among the cores. If not, I need to map them to L2SRAM by following your suggestion. Please note my application works correctly in both case.  Any suggestions for this ?"

    If you are using OpenMP runtime, then you only need to be concerned about the placement of the TLS block for the main thread. When other threads are created, the OpenMP runtime will alllocate space for and initialize their TLS blocks for you.

    It is recommended that you account for the main thread's TLS block allocation at link time by placing it in DDR3 as opposed to L2SRAM.allocate the main thread's TLS block (i.e. ".TI.tls: > DDR3").

    Hope this is helpful to you. Please let me know if you have further questions.

    Thanks and Regards,

    Todd Snider

    Compiler Support Team

    Texas Instruments Incorporated

  • 0 in reply to Todd Snider
    Guru 19890 points

    Hi Todd,

    Thanks you four help. Understood. Now I close the thread.

    Thanks,
    Naoki

  • 0 in reply to Naoki Kawada
    Prodigy 140 points

    Hello

    I have not close the warnings, yet.

    I understand what u have understood but i have not manage to overcome it.

    I tried to change linker cmd but after rebuilding the project the commands what ever you have changed are flow.

    I think the solution is changing the .cfg file maybe also changing .map file for standable solution. 

    I try to customize it but i couldnot manage .

    Could you write me the steps of solution?

    thanks