The ELF object file format uses program headers, also knows as
segments. The program headers describe how the program should be
loaded into memory. You can print them out by using the objdump
program with the ‘-p’ option.
When you run an ELF program on a native ELF system, the system loader reads the program headers in order to figure out how to load the program. This will only work if the program headers are set correctly. This manual does not describe the details of how the system loader interprets program headers; for more information, see the ELF ABI.
The linker will create reasonable program headers by default. However,
in some cases, you may need to specify the program headers more
precisely. You may use the PHDRS
command for this purpose. When
the linker sees the PHDRS
command in the linker script, it will
not create any program headers other than the ones specified.
The linker only pays attention to the PHDRS
command when
generating an ELF output file. In other cases, the linker will simply
ignore PHDRS
.
This is the syntax of the PHDRS
command. The words PHDRS
,
FILEHDR
, AT
, and FLAGS
are keywords.
PHDRS { name type [ FILEHDR ] [ PHDRS ] [ AT ( address ) ] [ FLAGS ( flags ) ] ; }
The name is used only for reference in the SECTIONS
command
of the linker script. It is not put into the output file. Program
header names are stored in a separate name space, and will not conflict
with symbol names, file names, or section names. Each program header
must have a distinct name. The headers are processed in order and it
is usual for them to map to sections in ascending load address order.
Certain program header types describe segments of memory which the system loader will load from the file. In the linker script, you specify the contents of these segments by placing allocatable output sections in the segments. You use the ‘:phdr’ output section attribute to place a section in a particular segment. See Output Section Phdr.
It is normal to put certain sections in more than one segment. This merely implies that one segment of memory contains another. You may repeat ‘:phdr’, using it once for each segment which should contain the section.
If you place a section in one or more segments using ‘:phdr’,
then the linker will place all subsequent allocatable sections which do
not specify ‘:phdr’ in the same segments. This is for
convenience, since generally a whole set of contiguous sections will be
placed in a single segment. You can use :NONE
to override the
default segment and tell the linker to not put the section in any
segment at all.
You may use the FILEHDR
and PHDRS
keywords after
the program header type to further describe the contents of the segment.
The FILEHDR
keyword means that the segment should include the ELF
file header. The PHDRS
keyword means that the segment should
include the ELF program headers themselves. If applied to a loadable
segment (PT_LOAD
), all prior loadable segments must have one of
these keywords.
The type may be one of the following. The numbers indicate the value of the keyword.
PT_NULL
(0)PT_LOAD
(1)PT_DYNAMIC
(2)PT_INTERP
(3)PT_NOTE
(4)PT_SHLIB
(5)PT_PHDR
(6)PT_TLS
(7)You can specify that a segment should be loaded at a particular address
in memory by using an AT
expression. This is identical to the
AT
command used as an output section attribute (see Output Section LMA). The AT
command for a program header overrides the
output section attribute.
The linker will normally set the segment flags based on the sections
which comprise the segment. You may use the FLAGS
keyword to
explicitly specify the segment flags. The value of flags must be
an integer. It is used to set the p_flags
field of the program
header.
Here is an example of PHDRS
. This shows a typical set of program
headers used on a native ELF system.
PHDRS { headers PT_PHDR PHDRS ; interp PT_INTERP ; text PT_LOAD FILEHDR PHDRS ; data PT_LOAD ; dynamic PT_DYNAMIC ; } SECTIONS { . = SIZEOF_HEADERS; .interp : { *(.interp) } :text :interp .text : { *(.text) } :text .rodata : { *(.rodata) } /* defaults to :text */ ... . = . + 0x1000; /* move to a new page in memory */ .data : { *(.data) } :data .dynamic : { *(.dynamic) } :data :dynamic ... }