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

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.

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

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.

Jason R Sachs said:

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.

Hi,

Sorry for posting on an old thread. I have a similar problem, I am using the -pm option to compile the program which compiles all of the files into a single .obj file. I want to place text of some objs in a separate section. Is there a way other than going to each function and writing a pragma for that.

Thanks,
Saurabh

An earlier post suggests an approach based on the build option --gen_func_subsections.  I still think that is your best choice.

Thanks and regards,

-George

The compiler has supported pragmas SET_CODE_SECTION and SET_DATA_SECTION for a while now, which do what I think you're asking for.  See your compiler user's guide section "The SET_CODE_SECTION and SET_DATA_SECTION Pragmas."

#pragma SET_CODE_SECTION("custom")
extern void func1();
extern void func2();
#pragma SET_CODE_SECTION()
extern void func3();

void func1() { call();  }
void func2() { call();  }
void func3() { call();  }