转载自http://processors.wiki.ti.com/index.php/Linker_Special_Section_Types#NOLOAD_Sections_2
Introduction
The linker allows you to create different kinds of sections called NOLOAD, DSECT, and COPY sections. How can you create these sections, and what are they good for?
Syntax
You can only create these section types in the SECTIONS directive of a linker command file. This example comes from the Assembly Language Tools User’s Guide …
SECTIONS
{
sec1: load = 0x00002000, type = DSECT {f1.obj}
sec2: load = 0x00004000, type = COPY {f2.obj}
sec3: load = 0x00006000, type = NOLOAD {f3.obj}
}
How are these sections different?
A regular section undergoes four processing steps:
- Allocated: Space is allocated in memory for the section.
- Relocated: Symbols defined in the section are relocated to their final addresses in memory. References to the section from outside are patched according to where the section is allocated. References inside the section to symbols outside the section are similarly patched to the final addresses.
- In Output: The section is placed in the output file.
- Loaded: The section is loaded to the target system.
Steps 1-3 are performed by the linker. Step 4 can be performed with a variety of methods. A section may be loaded by Code Composer Studio during a debug session, or burned into Flash memory, or any number of other methods for loading code or data to a target system.
Sections with these special types avoid one or more of these processing steps.
NOLOAD Sections
NOLOAD sections avoid steps 3 and 4. A NOLOAD section is not included in the output file. Because it is not in the output file, it is not loaded to the target system. Everything else is the same as a regular section.
COPY Sections
COPY sections avoid steps 1 and 4. Space is not allocated in memory for a COPY section. While a COPY section is in the output file, it is not loaded to the target. Everything else is the same as a regular section.
DSECT Sections
DSECT stands for Dummy Section. A DSECT only undergoes step 2, relocation. Space is not allocated in the memory map for a DSECT, nor does it appear in the output file. Thus, a DSECT is not loaded to the target. Any references to symbols in the DSECT are patched as if the section were allocated to the address given for the section. In the example above, the symbols for the DSECT are relocated starting at address 0x2000.
Summary on Section Processing
| Type | Allocated | Relocated | In Output | Loaded |
|---|---|---|---|---|
| Regular | X | X | X | X |
| NOLOAD | X | X | ||
| COPY | X | X | ||
| DSECT | X |
What are these sections good for?
NOLOAD Sections
NOLOAD sections are good for modeling parts of the code or data that are already present in the system. Common examples include code burned into ROM or Flash. The ROM code part of a system could be linked with a command file similar to this …
-a /* guarantee no refs to syms outside ROM */
-r /* partial link - will link again */
rom.obj
-o rom.out MEMORY {
ROM : ...
RAM : ...
} SECTIONS {
rom_sect : { *(.text) } > ROM
}
The resulting rom.out file could be burned in ROM. The final link could use a command file similar to …
rom.out /* code in ROM */
calls_rom.obj /* code that calls code in ROM */
-o calls_rom.out MEMORY { /* must be same as above */
ROM : ...
RAM : ...
} SECTIONS {
rom_sect : type=NOLOAD > ROM
calls_rom : { *(.text) } > RAM
}
The DSECT type could be used in place of NOLOAD. The advantage of NOLOAD is that, since space for the section is allocated in memory, allocations mistakes will be caught by the linker. Such mistakes include allocating too much code to a memory range, or allocating multiple sections to the same memory range. Because DSECT’s are not allocated space in memory, such mistakes go unchecked.
There are several other considerations when creating and linking against a ROM image. The examples above are not comprehensive. The focus is exclusively on explaining NOLOAD.
COPY Sections
COPY sections are rarely created directly by users. They are created automatically by the code generation tools to support various features.
When linking under the --ram_model (–cr) switch for RAM model initialization of global variables in C, the .cinit section is a COPY section. Linking with –-ram_model is similar to the following example
-u _c_int00
-e _c_int00 cinit = -1;
___cinit__ = cinit; SECTIONS {
.cinit {
*(.cinit)
. += 4; /* Mark end with 0 */
} fill = 0, type = COPY
}
The .cinit section is processed by a loader, such as the loader in Code Composer Studio, when loading an output file, to initialize the C global variables. This implies that the loader knows the format of the data contained in the .cinit section.
Program debug information, such as symbol records and source line number information, when organized according to the Dwarf debugging standards, is stored in COPY sections with names such as .debug_info, .debug_line, and .debug_abbrev. These sections are read by the Code Composer Studio in order to support debugging the system.
DSECT Sections
DSECT sections are rarely used. DSECT sections are not allocated to memory. Therefore, they can overlay any other section, whether DSECT or not. Thus, you need to be very careful about their use. It is easy to make a mistake that is hard to find.
Here is one example of the usage of DSECT. A source file contains four functions …
void ram1() { … }
void rom1() { … }
void ram2() { … }
void rom2() { … }
The RAM and ROM functions are separated into distinct sections with names similar to .text:_ram1. The ROM functions are burned into ROM. All of this is done with version X of the tools. After rebuilding with version X+1 of the tools, the sizes and starting addresses of all of the functions, including the ROM functions, is different. But the requirement is that the link must be done against the ROM burned from the previous build. It is possible to get the hard coded addresses of the ROM functions from the previous build. With all of that information, a link command file similar to this would work …
SECTIONS
{
.text:_rom1 : run = 0x1234, type = DSECT
.text:_rom2 : run = 0x5678, type = DSECT
}
Note the hard-coded addresses above are auto-generated from information in the previous build. Details of that process are beyond the scope of this article.
The result is that each ROM section is allocated exactly where it was in the previous build. NOLOAD would work for any function/section that is the same size or smaller than before. But it would not work in the case of a function which is larger. If NOLOAD were used in that case, the linker would complain about the function overlaying the starting address of a later function. Using DSECT, in effect, avoids that check