[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The ELF ABI permits a file to have either sections or segments or both. Relocateable object files conventionally have only sections. Executables conventionally have both. Core files conventionally have only program segments.
ELF sections are similar to sections in other object file formats: they have a name, a VMA, file contents, flags, and other miscellaneous information. ELF relocations are stored in sections of a particular type; BFD automatically converts these sections into internal relocation information.
ELF program segments are intended for fast interpretation by a system loader. They have a type, a VMA, an LMA, file contents, and a couple of other fields. When an ELF executable is run on a Unix system, the system loader will examine the program segments to decide how to load it. The loader will ignore the section information. Loadable program segments (type `PT_LOAD') are directly loaded into memory. Other program segments are interpreted by the loader, and generally provide dynamic linking information.
When an ELF file has both program segments and sections, an ELF program segment may encompass one or more ELF sections, in the sense that the portion of the file which corresponds to the program segment may include the portions of the file corresponding to one or more sections. When there is more than one section in a loadable program segment, the relative positions of the section contents in the file must correspond to the relative positions they should hold when the program segment is loaded. This requirement should be obvious if you consider that the system loader will load an entire program segment at a time.
On a system which supports dynamic paging, such as any native Unix system, the contents of a loadable program segment must be at the same offset in the file as in memory, modulo the memory page size used on the system. This is because the system loader will map the file into memory starting at the start of a page. The system loader can easily remap entire pages to the correct load address. However, if the contents of the file were not correctly aligned within the page, the system loader would have to shift the contents around within the page, which is too expensive. For example, if the LMA of a loadable program segment is `0x40080' and the page size is `0x1000', then the position of the segment contents within the file must equal `0x80' modulo `0x1000'.
BFD has only a single set of sections. It does not provide any generic way to examine both sections and segments. When BFD is used to open an object file or executable, the BFD sections will represent ELF sections. When BFD is used to open a core file, the BFD sections will represent ELF program segments.
When BFD is used to examine an object file or executable, any program segments will be read to set the LMA of the sections. This is because ELF sections only have a VMA, while ELF program segments have both a VMA and an LMA. Any program segments will be copied by the `copy_private' entry points. They will be printed by the `print_private' entry point. Otherwise, the program segments are ignored. In particular, programs which use BFD currently have no direct access to the program segments.
When BFD is used to create an executable, the program segments will be created automatically based on the section information. This is done in the function `assign_file_positions_for_segments' in `elf.c'. This function has been tweaked many times, and probably still has problems that arise in particular cases.
There is a hook which may be used to explicitly define the program segments when creating an executable: the `bfd_record_phdr' function in `bfd.c'. If this function is called, BFD will not create program segments itself, but will only create the program segments specified by the caller. The linker uses this function to implement the `PHDRS' linker script command.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |