輸入到鏈接器的文件被稱爲目標文件。 鏈接器產生一個圖像文件,該文件又被加載器用作輸入。VA(虛擬地址)&RVA(相對虛擬地址)
從A導語 「Microsoft可移植可執行文件和通用對象文件格式規範」
RVA(相對虛擬地址)。在圖像文件中, 被加載到內存後的地址,其中 的圖像文件的基地址被從中減去 。項目 的RVA幾乎總是不同於其在磁盤上的文件內的 位置(文件 指針)。
在一個目標文件中,RVA小於 有意義,因爲未分配內存位置 。在這種情況下,RVA 將是 (稍後在此表中描述)內的地址,至 ,其中重新定位稍後在鏈接期間應用 。爲簡單起見, 編譯器應將每個部分中的第一個RVA 設置爲零。
VA(虛擬地址)。與RVA相同,但不會減去 圖像文件的基址。 地址被稱爲「VA」,因爲 Windows爲每個進程創建獨立的VA空間 ,獨立於 物理內存。幾乎所有的 目的,一個VA應該被認爲是 只是一個地址。 VA不是可作爲RVA預測的 ,因爲 加載程序可能不會在其 首選位置加載圖像。
即使在閱讀本文後,我仍然不明白。我有很多問題。任何人都可以用實際的方式解釋它嗎?請遵守所述的術語Object File
& Image File
。
所有我知道的地址,是
- 無論在目標文件,也沒有在圖像文件,我們不知道確切的內存位置的話,
- 彙編而產生目標文件的地址計算相對於部分
.data
&.text
(對於函數名稱)。 - 將多個目標文件作爲輸入的鏈接器生成一個圖像文件。在生成時,它首先合併每個對象文件的所有部分,並在合併時重新計算相對於每個部分的地址偏移量。而且,沒有任何東西像全球偏移。
如果我知道什麼有問題,請糾正我。
編輯:
讀給弗朗西斯的回答後,我很清楚什麼物理地址,VA & RVA,什麼是它們之間的關係。
所有變量的RVA &方法在重定位期間必須由鏈接器計算。所以,(方法/變量的RVA的值)==(它從文件開始的偏移量)?一定是真的。但令人驚訝的是,它不是。爲什麼這樣?
我通過使用c:\WINDOWS\system32\kernel32.dll
PEView檢查這一點,並發現:
- RVA &的FileOffset是相同的,直到第年初(
.text
是在這個dll第一部分)。 - 從
.text
開始到.data
,.rsrc
直到最後一節的最後一個字節(.reloc
)RVA & FileOffset是不同的。 &也是第一節的第一個字節的RVA是「始終」顯示爲0x1000
- 有趣的是每個節的字節在FileOffset中是連續的。我的意思是另一節開始於節的最後一個字節的下一個字節。但是,如果我在RVA中看到同樣的事情,則這些是節的最後一個字節的RVA與下一節的第一個字節之間的巨大差距。
我的猜測:
所有,數據的第一個(
.text
這裏)之前已 字節 節「而不是」實際加載 到進程的VA空間,這些 數據字節僅用於 定位&描述這些部分。 它們可以被稱爲「meta section data」。因爲它們沒有裝入VA 過程的空間。 術語RVA的用法也沒有意義,這是 之所以爲
RVA == FileOffset
這些字節。由於,
- RVA術語有效期爲只有那些將被實際裝載 到VA空間字節。
.text
,.data
,.rsrc
,.reloc
的字節是這樣的字節。- 取代從RVA開始
0x00000
PEView軟件從0x1000
開始 。
我不明白爲什麼第三次觀察。我無法解釋。
謝謝你這麼清楚的解釋。只有一個建議,你可以在RVA例子中把'Process A'的名字改成'Process X'。因爲DLL A和進程A都可能導致混淆。 :) – claws 2010-02-01 06:01:38
我已經將DLL A更改爲DLL C.還對文本的某些部分進行了細化以防止混淆。 – Francis 2010-02-01 06:07:06
我已經擴展了我的查詢。你可以看看嗎? – claws 2010-02-01 08:59:32