Espressif ESP32-S2 Programming Manual page 1430

Chapter 4. API Guides
entity1 (scheme1);
section1 -> target1 KEEP() ALIGN(4, pre, post),
section2 -> target2 SURROUND(sym) ALIGN(4, post) SORT()
Putting it all together, the following mapping fragment, for example,
[mapping:name]
archive: lib1.a
entries:
obj1 (noflash);
rodata -> dram0_data KEEP() SORT() ALIGN(8) SURROUND(my_sym)
generates an output on the linker script:
. = ALIGN(8)
_my_sym_start = ABSOLUTE(.)
KEEP(lib1.a:obj1.*( SORT(.rodata) SORT(.rodata.*) ))
_my_sym_end = ABSOLUTE(.)
Note that ALIGN and SURROUND, as mentioned in the flag descriptions, are order sensitive. Therefore, if for the
same mapping fragment these two are switched, the following is generated instead:
_my_sym_start = ABSOLUTE(.)
. = ALIGN(8)
KEEP(lib1.a:obj1.*( SORT(.rodata) SORT(.rodata.*) ))
_my_sym_end = ABSOLUTE(.)
On Symbol-Granularity Placements
ffunction-sections and -ffdata-sections. ESP-IDF compiles with these flags by default. If the user
opts to remove these flags, then the symbol-granularity placements will not work. Furthermore, even with the pres-
ence of these flags, there are still other limitations to keep in mind due to the dependence on the compiler's emitted
output sections.
For example, with -ffunction-sections, separate sections are emitted for each function; with section names
predictably constructed i.e. .text.{func_name} and .literal.{func_name}. This is not the case for
string literals within the function, as they go to pooled or generated section names.
With -fdata-sections, for global scope data the compiler predictably emits either .data.{var_name},
.rodata.{var_name} or .bss.{var_name}; and so Type I mapping entry works for these. However,
this is not the case for static data declared in function scope, as the generated section name is a result of mangling
the variable name with some other information.
Linker Script Template
The linker script template is the skeleton in which the generated placement rules are put into. It is an otherwise
ordinary linker script, with a specific marker syntax that indicates where the generated placement rules are placed.
To reference the placement rules collected under a target token, the following syntax is used:
mapping[target]
Example:
The example below is an excerpt from a possible linker script template. It defines an output section .iram0.text,
and inside is a marker referencing the target iram0_text.
.iram0.text :
{
/* Code marked as runnning out of IRAM */
Espressif Systems
Symbol granularity placements is possible due to compiler flags -
1419
Submit Document Feedback
(continued from previous page)
(continues on next page)
Release v4.4