ELF (Executable and Linking Format) doc
This is a collection of information about ELF,
the
Executable and Linking Format
employed in IRIX 5 and beyond.
Executable and Linking Format
Previous versions of IRIX used an extended version of the Common Object File
Format (COFF) for object files. The current compiler system produces ELF
object files. ELF is the format specified by the System V Release 4
Applications Binary Interface (the SVR4 ABI). In addition, ELF provides
support for Dynamic Shared Objects, described below. Types of ELF object
files include:
- Relocatable files contain code and data in a format suitable
for linking with other object files to make a shared object or executable.
- Dynamic Shared Objects contain code and data suitable for dynamic
linking. Relocatable files may be linked with DSOs to create a
dynamic executable. At run time, the run-time linker combines the
executable and DSOs to produce a process image.
- Executable files are programs ready for execution. They may or may not
be dynamically linked.
COFF executables continue to run on releases of IRIX prior to IRIX 6,
but the current compiler system has no facility for creating or linking COFF
executables. COFF and ELF object files may not be linked together. To
take advantage of new IRIX features, you must recompile your code.
IRIX executes all binaries that are compliant with the SVR4 ABI, as
specified in the System V Applications Binary Interface - Revised
Edition and the System V ABI MIPS Processor Supplement. However,
binaries compiled under this version of the compiler system are not
guaranteed to comply with the SVR4 ABI. The MIPS-specific version of
the SVR4 ABI is referred to as the MIPS ABI. Programs that comply
with the MIPS ABI can be run on any machine that supports the MIPS ABI.
- elspec.html: Controlling a Program's Layout with ELSPEC, November, 1995
Using apropos(1) (with the argument of "elf"), the
man pages included below were fished out of the
IRIX 6.2 doc sea.
- dso(5) DSO - Dynamic Shared Object
TOPIC
This man page is intended to be both a quick reference and a source of
detailed information on Dynamic Shared Objects. It is divided into 4
sections:
General Information and Overview
Linking/Building Suggestions
Performance Considerations
Frequently Asked Questions and Detailed Discussions
GENERAL INFORMATION AND OVERVIEW
Format
A DSO, or Dynamic Shared Object, is an ELF format object file,
very
similar in structure to an executable program but with no "main". It has
a shared component, consisting of shared text and read-only data; a
private component, consisting of data and the GOT (Global Offset Table);
several sections that hold information necessary to load and link the
object; and a liblist, the list of other shared objects referenced by
this object. Most of the libraries supplied by SGI are available as
dynamic shared objects.
PIC -- Position Independent Code
A DSO is relocatable at runtime; it can be loaded at any virtual address.
A consequence of this is that all references to external symbols must be
resolved at runtime. References from the private region (.e.g. from
private data) are resolved once at load-time; references from the shared
region (e.g. from shared text) must go through an indirection table (GOT)
and hence have a small performance penalty associated with them.
Code compiled for use in a shared object is referred to as PIC whereas
non-PIC is usually referred to as non-shared. Non-shared code and PIC can
not be mixed in the same object.
What Happens at Runtime?
Exec loads the main program and then loads rld(1), the runtime linking
loader, which finishes the exec operation. Starting with main's liblist,
rld loads each shared object on the list that is not marked as delay load, reads that object's liblist, and repeats the operation until all
shared objects have been loaded. Next, rld allocates common and fixes up
symbolic references in each loaded object. (This is necessary because we
don't know until runtime where the object will be loaded.) Next, each
object's init code is executed. Finally, control is transferred to
"__start".
Be sure to read about quickstart, delayed loads, sgidladd(3), and
dlopen(3) as each can affect this general process.
- elf(4) - Executable and Linking Format (ELF) files
The file name a.out is the default ELF-format output file name from the
link editor ld(1). The link editor will make an a.out executable if
there were no errors and no unresolved external references.
Programs that manipulate ELF files may use the library described in
elf(3E). An overview of the file format follows. For more complete
information, see the references given below.
- elfdump(5) -- dumps selected parts of a 32-bit
or a 64-bit ELF object file/archive and displays them in ELF style
- elspec(5) -- ELF Layout specification
TOPIC
This manpage describes the ELF Layout Specification language implemented
by ld(1) which allows users to exactly specify layout of object files,
programs, and shared objects.
INTRODUCTION
It is often desirable to specify the exact layout of an executable file.
Some of the uses of this might be embedded systems, thread-local data
layout, reducing cache conflicts, reducing false sharing, reducing memory
utilization. The current linker allows exact specifcation of layout via
the ELF Layout Specification language.
- ld(1)
- rqsall(1)
- rqsprint(1)
- rqsread(1)
- dwarfdump
- elf(3E)
- elf_begin(3E)
- elf_cntl(3E)
- elf_end(3E)
- elf_error(3E)
- elf_fill(3E)
- elf_flag(3E)
- elf_fsize(3E)
- elf_getarhdr(3E)
- elf_getarsym(3E)
- elf_getbase(3E)
- elf_getdata(3E)
- elf_getehdr(3E)
- elf_getident(3E)
- elf_getphdr(3E)
- elf_getshdr(3E)
- elf_hash(3E)
- elf_kind(3E)
- elf_next(3E)
- elf_rawfile(3E)
- elf_strptr(3E)
- elf_update(3E)
- elf_version(3E)
- elf_xlate(3E)
OR, ...
Copyright © 1995-96, Silicon Graphics, Inc.