.section directive to assemble the following code into a section
This directive is only supported for targets that actually support arbitrarily
named sections; on
a.out targets, for example, it is not accepted, even
with a standard
a.out section name.
For COFF targets, the
.section directive is used in one of the following
.section name[, "flags"] .section name[, subsection]
If the optional argument is quoted, it is taken as flags to use for the section. Each flag is a single character. The following flags are recognized:
If no flags are specified, the default flags depend upon the section name. If
the section name is not recognized, the default will be for the section to be
loaded and writable. Note the
w flags remove attributes
from the section, rather than adding them, so if they are used on their own it
will be as if no flags had been specified at all.
If the optional argument to the
.section directive is not quoted, it is
taken as a subsection number (see Sub-Sections).
This is one of the ELF section stack manipulation directives. The others are
.subsection (see SubSection),
.popsection (see PopSection), and
.previous (see Previous).
For ELF targets, the
.section directive is used like this:
.section name [, "flags"[, @type[,flag_specific_arguments]]]
If the `--sectname-subst' command-line option is provided, the name
argument may contain a substitution sequence. Only
%S is supported
at the moment, and substitutes the current section name. For example:
.macro exception_code .section %S.exception [exception code here] .previous .endm .text [code] exception_code [...] .section .init [init code] exception_code [...]
exception_code invocations above would create the
.init.exception sections respectively.
This is useful e.g. to discriminate between anciliary sections that are
tied to setup code to be discarded after use from anciliary sections that
need to stay resident without having to define multiple
macros just for that purpose.
The optional flags argument is a quoted string which may contain any combination of the following characters:
Note - once a section's flags have been set they cannot be changed. There are
a few exceptions to this rule however. Processor and application specific
flags can be added to an already defined section. The
.symtab sections can have the allocate flag
a) set after they are initially defined, and the
section may have the executable (
x) flag added.
The optional type argument may contain one of the following constants:
Many targets only support the first three section types. The type may be enclosed in double quotes if necessary.
Note on targets where the
@ character is the start of a comment (eg
ARM) then another character is used instead. For example the ARM port uses the
Note - some sections, eg
.data are considered to be
special and have fixed types. Any attempt to declare them with a different
type will generate an error from the assembler.
If flags contains the
M symbol then the type argument must
be specified as well as an extra argument—entsize—like this:
.section name , "flags"M, @type, entsize
Sections with the
M flag but not
S flag must contain fixed size
constants, each entsize octets long. Sections with both
S must contain zero terminated strings where each character is
entsize bytes long. The linker may remove duplicates within sections with
the same name, same entity size and same flags. entsize must be an
absolute expression. For sections with both
S, a string
which is a suffix of a larger string is considered a duplicate. Thus
"def" will be merged with
"abcdef"; A reference to the first
"def" will be changed to a reference to
If flags contains the
G symbol then the type argument must
be present along with an additional field like this:
.section name , "flags"G, @type, GroupName[, linkage]
The GroupName field specifies the name of the section group to which this particular section belongs. The optional linkage field can contain:
Note: if both the M and G flags are present then the fields for the Merge flag should come first, like this:
.section name , "flags"MG, @type, entsize, GroupName[, linkage]
If flags contains the
? symbol then it may not also contain the
G symbol and the GroupName or linkage fields should not be
? says to consider the section that's current before
this directive. If that section used
G, then the new section will use
G with those same GroupName and linkage fields implicitly.
If not, then the
? symbol has no effect.
If no flags are specified, the default flags depend upon the section name. If the section name is not recognized, the default will be for the section to have none of the above flags: it will not be allocated in memory, nor writable, nor executable. The section will contain data.
For ELF targets, the assembler supports another type of
directive for compatibility with the Solaris assembler:
.section "name"[, flags...]
Note that the section name is quoted. There may be a sequence of comma separated flags:
This directive replaces the current section and subsection. See the
contents of the gas testsuite directory
some examples of how this directive and the other section stack directives