You can include explicit bytes of data in an output section by using
BYTE, SHORT, LONG, QUAD, or SQUAD as
an output section command. Each keyword is followed by an expression in
parentheses providing the value to store (see Expressions in Linker Scripts). The
value of the expression is stored at the current value of the location
counter.
The BYTE, SHORT, LONG, and QUAD commands
store one, two, four, and eight bytes (respectively). After storing the
bytes, the location counter is incremented by the number of bytes
stored.
For example, this will store the byte 1 followed by the four byte value of the symbol ‘addr’:
BYTE(1) LONG(addr)
When using a 64 bit host or target, QUAD and SQUAD are the
same; they both store an 8 byte, or 64 bit, value. When both host and
target are 32 bits, an expression is computed as 32 bits. In this case
QUAD stores a 32 bit value zero extended to 64 bits, and
SQUAD stores a 32 bit value sign extended to 64 bits.
If the object file format of the output file has an explicit endianness, which is the normal case, the value will be stored in that endianness. When the object file format does not have an explicit endianness, as is true of, for example, S-records, the value will be stored in the endianness of the first input object file.
You can include a zero-terminated string in an output section by using
ASCIZ. The keyword is followed by a string which is stored at
the current value of the location counter adding a zero byte at the
end. If the string includes spaces it must be enclosed in double
quotes. The string may contain ’\n’, ’\r’, ’\t’ and octal numbers.
Hex numbers are not supported.
For example, this string of 16 characters will create a 17 byte area
ASCIZ "This is 16 bytes"
Note—these commands only work inside a section description and not between them, so the following will produce an error from the linker:
SECTIONS { .text : { *(.text) } LONG(1) .data : { *(.data) } } whereas this will work:
SECTIONS { .text : { *(.text) ; LONG(1) } .data : { *(.data) } } You may use the FILL command to set the fill pattern for the
current section. It is followed by an expression in parentheses. Any
otherwise unspecified regions of memory within the section (for example,
gaps left due to the required alignment of input sections) are filled
with the value of the expression, repeated as
necessary. A FILL statement covers memory locations after the
point at which it occurs in the section definition; by including more
than one FILL statement, you can have different fill patterns in
different parts of an output section.
This example shows how to fill unspecified regions of memory with the value ‘0x90’:
FILL(0x90909090)
The FILL command is similar to the ‘=fillexp’ output
section attribute, but it only affects the
part of the section following the FILL command, rather than the
entire section. If both are used, the FILL command takes
precedence. See Output Section Fill, for details on the fill
expression.
Note - normally the value of expression is zero extended to 4
bytes when used to fill gaps. Thus ‘FILL(144)’ will fill a
region with repeats of the pattern ‘0 0 0 144’. The value is
treated as a big-endian number, so for example
‘FILL(22 * 256 + 23)’ will fill the region with repeats of the
pattern ‘0 0 22 23’. If the expression results in a value with
more than 4 significant bytes only the least 4 bytes of the value will
be used.
The above rules do not apply when the expression is a simple
hexadecimal number. In this case zero extension is not performed and
all bytes are significant. So ‘FILL(0x90)’ will fill a region with
repeats of ‘0x90’ with no zero bytes, and ‘FILL(0x9192)’
will fill the region with repeats of ‘0x91 0x92’. Zero bytes
in a hexadecimal expression are significant even at the start, so
‘FILL(0x0090)’ will fill a region with repeats of ‘0x00 0x90’.
Hexadecimal numbers can be longer than 4 bytes, and all of the bytes are significant, so ‘FILL(0x123456789a)’ will fill a region with repeats of the 5 byte sequence ‘0x12 0x34 0x56 0x78 0x9a’. Excess bytes in a hexadecimal value beyond the size of a region will be silently ignored.
The above only applies to hexadecimal numbers specified as ‘0x[0-9][a-f][A-F]’. Hexadecimal numbers specified with a ‘$’ prefix, or a ‘h’, ‘H’, ‘x’ or ‘X’ suffix will follow the normal fill value rules. This also applies to expressions that involve hexadecimal numbers, and hexadecimal numbers that have a magnitude suffix.
The LINKER_VERSION command inserts a string containing the
version of the linker at the current point. Note - by default this
directive is disabled and will do nothing. It only becomes active if
the --enable-linker-version command line option is used.
Built-in linker scripts for ELF based targets already include this directive in their ‘.comment’ section.