• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Development Tools » TI C/C++ Compiler » TI C/C++ Compiler - Forum » #pragma CODE_SECTION: applying to files / groups of functions?
Share
TI C/C++ Compiler
  • Forum
Options
  • Subscribe via RSS

#pragma CODE_SECTION: applying to files / groups of functions?

#pragma CODE_SECTION: applying to files / groups of functions?

This question is answered
Jason R Sachs
Posted by Jason R Sachs
on Apr 12 2010 14:58 PM
Expert1870 points

Is there a way in C++ to make the #pragma CODE_SECTION (" section name "); apply to a block of functions or the whole file?

It's a real pain to stick it in front of each and every function.

Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • Lori Heustess
    Posted by Lori Heustess
    on Apr 12 2010 16:58 PM
    Suggested Answer
    Guru50925 points

    Jason R Sachs

    Is there a way in C++ to make the #pragma CODE_SECTION (" section name "); apply to a block of functions or the whole file?

    It's a real pain to stick it in front of each and every function.

    In the linker .cmd file you can group code generated by different files (by specifying the .obj) into one section.  The linker .cmd file is documented in chapter 7 the Assembly Tools ref guide (www.ti.com/lit/spru513).   Take a look at Section 7.8.3 -

    SECTIONS
    {
        .text : /* Build .text output section */
        {
            f1.obj(.text)      /* Link .text section from f1.obj */
            f2.obj(sec1)       /* Link sec1 section from f2.obj */
            f3.obj             /* Link ALL sections from f3.obj */
            f4.obj(.text,sec2) /* Link .text and sec2 from f4.obj */
        }
    }
    
    -Lori
    Did a reply answer your question? If yes, please click the "yes" button located at the bottom of that post.
    Visit these helpful C2000 Links!
    C2000 TI Wiki Pages
    TI Forum Sitemap
    ControlSUITE
    C2000 Getting Started
    CLA FAQs
    Workshop Material!
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Jason R Sachs
    Posted by Jason R Sachs
    on Apr 12 2010 17:13 PM
    Expert1870 points

    Hmm. I guess that helps somewhat.

    Please consider adding another #pragma option to the tools so the designation of which section the compiler sticks the function in can be handled more easily within the source code.

    The approach you suggest is ok if you want to hard-code the section allocations in the linker file. I would prefer a two-level-of-indirection approach, some kind of "pseudosection" e.g. from the source code's point of view, you just name the "pseudosections" with particular tags without knowing where they're going, to specify which functions should be kept together, and in the linker file, you specify that "pseudosections" foo and bar go into the .text section, whereas "pseudosections" baz and quux go into the "ramfuncs" section.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Lori Heustess
    Posted by Lori Heustess
    on Apr 13 2010 09:43 AM
    Verified Answer
    Verified by George Mock
    Guru50925 points

    Hi Jason,

    I'm gong to move this thread to the compiler forum so they can see your feedback and possibly give more suggestions.

    Jason R Sachs
    I would prefer a two-level-of-indirection approach, some kind of "pseudosection" e.g. from the source code's point of view, you just name the "pseudosections" with particular tags without knowing where they're going, to specify which functions should be kept together, and in the linker file, you specify that "pseudosections" foo and bar go into the .text section, whereas "pseudosections" baz and quux go into the "ramfuncs" section.

    If I understand what you would like - this can be done today - you can name as many sections in the code as you like and then assign them wherever they should be in the .cmd file.  So maybe there is a section called SYS_INIT and another called BAZ and another called QUUX and they are placed where is appropriate. 

    I suggested referencing the .obj name in the linker file since you mentioned wanting to assign all the functions within a particular file to a section.  It doesn't have to go into .text.

    Best Regards

    Lori

     

     

    Did a reply answer your question? If yes, please click the "yes" button located at the bottom of that post.
    Visit these helpful C2000 Links!
    C2000 TI Wiki Pages
    TI Forum Sitemap
    ControlSUITE
    C2000 Getting Started
    CLA FAQs
    Workshop Material!
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • George Mock
    Posted by George Mock
    on Apr 14 2010 12:37 PM
    Guru51495 points

    Another alternative to consider ... Build with the option -mo (AKA --gen_func_subsections).  That places each function in a section of the form ".text:_function_name".  Then in the link command file you can write ...

    .text:_function_name > SPECIAL_MEMORY

    Or even ...

    special_output_section {
       .text:_f1
       .text:_f2
       ...
    } > SPECIAL_MEMORY

    The general idea is that there is a obvious correspondence between a function and the input section which contains it.

    Thanks and regards,

    -George

     


    TI C/C++ Compiler Forum Moderator
    Please click Verify Answer on the best reply to your question.
    The Compiler Wiki answers most common questions.
    Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.

    linker
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Jason R Sachs
    Posted by Jason R Sachs
    on May 12 2010 10:15 AM
    Expert1870 points

    I appreciate the possible alternatives available at present, + will figure out which is best for the time being, but none of them are particularly attractive.

    To clarify:

    1) In my source file I would like to map a function or group of functions to a named group G1 which does not know anything about the linker file content.

    2) In the linker file, I would like to map one or more groups G1, G2, G3 to a particular area of memory, which does not know anything about the names of the functions contained in the groups. This gives good decoupling between source file and linker file.

    Right now it is possible to do this, with two big drawbacks, by using named sections as the groups. The two exceptions are:

    a) all the ways to map functions to a named section involve either individually calling out section names (with "#pragma CODE_SECTION(SECTION_NAME);") for each function in the source file, or for the linker command file (via the -mo option George mentioned, which has tight coupling between linker file and source code), or handling things on a file-by-file basis.

    b) If you want memory to be loaded into FLASH but executed out of RAM, then you have to handle this on a section-by-section basis in the linker file, and copy each section from FLASH to RAM in the startup code. So if you have more than one section, it involves kind of an excessive amount of setup. I guess a solution to this is to make named preprocessor aliases like:

    <begin file section_map.h>

    #define SECTION_RAMFUNCS "ramfuncs"

    #define SEC_ISR SECTION_RAMFUNCS

    #define SEC_ADC SECTION_RAMFUNCS

    <end file section_map.h>

    and then use #pragma CODE_SECTION(SEC_ISR) or #pragma CODE_SECTION(SEC_ADC) in the code to provide a level of indirection.

     

    In any case, you should think about how to improve this in future versions of the compiler/linker. Modularity and loose coupling are really important. There's too many ways for us humans to make errors, so having to mention the same function name twice in two separate locations (once in a source file, once in a compile script or in a linker file) in order to have the proper section mapping, is a potential source of errors.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Jason R Sachs
    Posted by Jason R Sachs
    on May 12 2010 10:23 AM
    Expert1870 points

    Jason R Sachs

    b) If you want memory to be loaded into FLASH but executed out of RAM, then you have to handle this on a section-by-section basis in the linker file, and copy each section from FLASH to RAM in the startup code. So if you have more than one section, it involves kind of an excessive amount of setup. I guess a solution to this is to make named preprocessor aliases like:

    <begin file section_map.h>

    #define SECTION_RAMFUNCS "ramfuncs"

    #define SEC_ISR SECTION_RAMFUNCS

    #define SEC_ADC SECTION_RAMFUNCS

    <end file section_map.h>

    and then use #pragma CODE_SECTION(SEC_ISR) or #pragma CODE_SECTION(SEC_ADC) in the code to provide a level of indirection.

    Or I guess I could handle it in the linker file (probably a better approach) per SPRU513C p. 181-182:

    SECTIONS
    {
    .text: { *(.text) }
    .data: { *(.data) }
    .bss: { *(.bss) }
    }
    The specification *(.text) means the unallocated .text sections from all the input files. This format is useful
    when:
    · You want the output section to contain all input sections that have a specified name, but the output
    section name is different from the input sections' name.
    · You want the link step to allocate the input sections before it processes additional input sections or
    commands within the braces.

     

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
TI E2E™ Community
  • Support Forums
  • Blogs
  • Videos
  • Groups
  • Site Support & Feedback
  • Settings
TI E2E™ Community Groups
  • TI University Program
  • Make the Switch
  • Microcontroller Projects
  • Motor Drive & Control
Other Communities
  • Deyisupport
  • Designsomething.org
  • beagleboard.org
  • TI on Element 14
  • TI on TechXchangeSM
Other Technical & Support Resources
  • WEBENCH® Design Center
  • Product Information Centers
  • Technical Documents
  • TI Design Network
  • TI Technical Articles
  • TI Training

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use