# 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:
1. Allocated: Space is allocated in memory for the section.
2. 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.
3. In Output: The section is placed in the output file.
4. 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.
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. However, they are not loaded into system memory
for execution.
## 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.