1. 程式人生 > >工具介面標準(TIS)可執行連結格式(ELF)規範-卷III-附錄A-Intel架構和System V Release 4依賴(二)

工具介面標準(TIS)可執行連結格式(ELF)規範-卷III-附錄A-Intel架構和System V Release 4依賴(二)

本文是對Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2的翻譯
工具介面標準(TIS)可執行連結格式(ELF)規範版本 1.2

翻譯以中英對照方式,英語水平有限,如有翻譯不當的地方,請諒解。

Program Loading and Dynamic Linking

程式載入和動態連結

ProgramLoading

程式載入

As the system creates or augmentsa process image, it logically copies a file's segment to a virtual memorysegment. When—and if— the system physically reads the file depends on theprogram's execution behavior, system load, and so on. A process does not requirea physical page unless it references the logical page during execution, andprocesses commonly leave many pages unreferenced. Therefore delaying physicalreads frequently obviates them, improving system performance. To obtain thisefficiency in practice, executable and shared object files must have segmentimages whose file offsets and virtual addresses are congruent, modulo the pagesize.

   當系統建立或增加一個程序映像,它邏輯上拷貝一個檔案的分段到一個虛擬記憶體分段。當假如系統在物理上依賴於程式執行行為來讀取檔案時,系統載入對應的分段。一個程序不會請求一個物理頁面,除非它在執行期間引用了對應的邏輯頁面,並且系統通常許多頁面都是未引用的。延遲物理上頻繁的讀取頁面來提高系統性能。為了在實際上獲得這樣的效率,可執行和共享物件檔案必須使分段映像的檔案偏移和虛擬地址是一致的,都以頁面大小取模。

Virtual addresses and file offsetsfor the Intel architecture segments are congruent modulo 4KB (0x1000) or largerpowers of 2. Because 4KB is the maximum page size for the Intel Architecture,the files will be suitable for paging regardless of physical page size.

     虛擬地址和檔案偏移對Intel架構下的分段來說是一致的,都以4K(0x1000)取模或更大的2的冪。因為4KB是Intel架構最大頁面大小,所以不管物理頁面大小,檔案會適合分頁。

FigureA-4. Executable File Example

圖A-4.可執行檔案例子

File Offset

File

Virtual Address

0

Program Header Table

Other Information

0x100

Text Segment

0x2be00 Bytes

0x8048100

0x8073eff

0x2bf00

Data Segment

0x4ee00 Bytes

0x8074f00

0x8079cff

0x30d00

Other Information

Figure A-5 describes theExecutable File Example in Figure A-4.

圖A-5描述了圖A-4這個可執行檔案例子

FigureA-5. Program Header Segments

圖A-5.程式頭分段

成員(Member)

文字(Text)

資料(Data)

p_type

p_offset

p_vaddr

p_paddr

p_filesz

p_memsz

p_flags

p_align

PT_LOAD

0x100

0x8048100

unspecified

0x2be00

0x2be00

PF_R+PF_X

0x1000

PT_LOAD

0x2bf00

0x8074f00

unspecified

0x4e00

0x5e24

PF_R+PF_W+PF_X

0x1000

Although the example's fileoffsets and virtual addresses are congruent modulo 4KB for both text and data,up to four file pages hold impure text or data (depending on page size and filesystem block size).

• The first text page contains the ELF header, the program header table,and other information.

• The last text page holds a copy of the beginning of data.

• The first data page has a copy of the end of text.

• The last data page may contain file information not relevant to therunning process.

雖然這個例子的檔案偏移和虛擬地址對文字和資料都是一致的以4K取模,直到4K檔案頁有不純的文字或資料(依賴於頁面大小和檔案系統塊大小).

  • 第一個文字頁包含ELF頭,程式頭和其它資訊;
  • 最後一個文字頁有資料開始的部分的拷貝;
  • 第一個資料頁有文字尾部的拷貝;
  • 最後的資料頁可能包含和執行程序不相關的檔案資訊。

Logically, the system enforces thememory permissions as if each segment were complete and separate; segments'addresses are adjusted to ensure each logical page in the address space has asingle set of permissions. In the example above, the region of the file holdingthe end of text and the beginning of data will be mapped twice: at one virtualaddress for text and at a different virtual address for data.

邏輯上,系統強制記憶體許可權就像每個分段是完整的及分離的;分段地址被調整到確保每個邏輯頁面在地址空間有一個單一的許可權集。在上面的例子中,檔案包含文字的尾部及資料的開始部分的區域將被對映兩次:在一個文字虛擬地址和一個不同的資料虛擬地址。

The end of the data segmentrequires special handling for uninitialized data, which the system defines tobegin with zero values. Thus if a file's last data page includes informationnot in the logical memory page, the extraneous data must be set to zero, not theunknown contents of the executable file. "Impurities'' in the other threepages are not logically part of the process image; whether the system expungesthem is unspecified. The memory image for this program follows, assuming 4 KB(0x1000 pages).

   資料分段尾部的未初始化資料需要特殊的處理,系統使用0來初始化該部分。從而假如一個檔案最後的資料頁面包含不在邏輯記憶體頁面的資訊,這些外部的資料必須被設定為0,不是可執行檔案的未知內容。在其它4個頁面的“雜質”不是這個程序映像的邏輯部分;系統是否擦出它們是未指定的。以下這個程式的記憶體映像假設4KB(0x1000頁面)對齊。

FigureA-6.  Process Image Segments Example

圖A-6.程序映像分段舉例

Virtual Address

Contents

Segment

0x8048000

Header Padding

0x100 Bytes

0x8048100

Text Segment

0x2be00 Bytes

Text

0x8073f00

Data Padding

0x100 Bytes

0x8074000

Text Padding

0xf00 Bytes

0x8074f00

Data Segment

0x4e00 Bytes

Data

0x80779d00

0x1024 Zero Bytes

Uninitialized Data

0x807ad24

0x2dc Zero Bytes

Page Padding

One aspect of segment loadingdiffers between executable files and shared objects. Executable file segmentstypically contain absolute code. To let the process execute correctly, thesegments must reside at the virtual addresses used to build the executablefile. Thus the system uses the p_vaddr values unchanged as virtual addresses.

在可執行檔案盒共享物件間,分段載入的樣子是不同的。可執行檔案分段有代表性的包含絕對程式碼。為了使程序正確執行,分段必須位於用於建立可執行檔案的虛擬地址。從而系統使用不改變的p_vaddr值作為虛擬地址。

On the other hand, shared object segmentstypically contain position-independent code. This lets a segment's virtualaddress change from one process to another, without invalidating executionbehavior. Though the system chooses virtual addresses for individual processes,it maintains the segments relative positions. Because position-independent codeuses relative addressing between segments, the difference between virtualaddresses in memory must match the difference between virtual addresses in thefile. The following table shows possible shared object virtual addressassignments for several processes, illustrating constant relative positioning.The table also illustrates the base address computations.

   另一方面,共享物件分段有代表性的包含位置無關程式碼。這使得一個分段的虛擬地址能夠在程序間不同,而不會導致執行行為無效。儘管系統為每個程序選擇虛擬地址,但它維護分段的相對位置。因為位置無關的程式碼在分段間使用相對地址,在記憶體中虛擬地址的不同必須和檔案中虛擬地址的不同相匹配。以下的表格顯示了為一些程序分配的可能的共享物件虛擬地址,闡明瞭不變的相對位置。這個表格也闡明瞭基地址計算。

FigureA-7.  Shared Object Segment AddressesExample

圖A-7.共享物件分段地址舉例

源(Source)

文字(Text)

資料(Data)

基地址(Base Address)

File

Process 1

Process 2

Process 3

Process 4

0x200

0x80000200

0x80081200

0x900c0200

0x900c6200

0x2a400

0x8002a400

0x800ab400

0x900ea400

0x900f0400

0x0

0x80000000

0x80081000

0x900c0000

0x900c6000