----------------------------------------------------------------------------

Program interpreter

An executable file may have one PT_INTERP program header element. During
exec(), the system retrieves a path name from the PT_INTERP segment and
creates the initial process image from the interpreter file's segments.
Instead of using the original executable file's segment images, the system
composes a memory image for the interpreter. It then is the interpreter's
responsibility to receive control from the system and provide an environment
for the application program.

The interpreter receives control in one of two ways. First, it may receive a
file descriptor to read the executable file, positioned at the beginning. It
can use this file descriptor to read and/or map the executable file's
segments into memory. Second, depending on the executable file format, the
system may load the executable file into memory instead of giving the
interpreter an open file descriptor. With the possible exception of the file
descriptor, the interpreter's initial process state matches what the
executable file would have received. The interpreter itself may not require
a second interpreter. An interpreter may be either a shared object or an
executable file.

   * A shared object (the normal case) is loaded as position-independent,
     with addresses that may vary from one process to another; the system
     creates its segments in the dynamic segment area used by mmap() and
     related services. Consequently, a shared object interpreter typically
     will not conflict with the original executable file's original segment
     addresses.

   * An executable file is loaded at fixed addresses; the system creates its
     segments using the virtual addresses from the program header table.
     Consequently, an executable file interpreter's virtual addresses may
     collide with the first executable file; the interpreter is responsible
     for resolving conflicts.