原 線性位址到實體地址轉換後記

之前想手動查詢線性位址對應的實體地址，以更好的理解作業系統的分頁機制，cr3的值和指定程序的eprocess的值總是對不上。

具體參考筆記[原]線性位址到實體地址轉換

今天突然靈光一閃，想起來張老師說過的關於cr3的相關知識，cr3是作業系統在切換程序的時候才會更新的，我們用.process /p 指定

特定程序的時候，cr3的值是中斷到偵錯程式那一刻正在執行的程序的頁目錄基址(pdb)，而不是我們指定的程序的頁目錄基址，所以不一樣是很正常的。換句話說.process /p只指定此刻我們想操作哪個程序，比如下斷點啊什麼的，都是針對我們指定的程序。

如果我們想讓cr3和eprocess值一樣，我們可以這樣。

.process /p notepad_eprocess

.reload /user

bp api

g一會當notepad呼叫指定的api時就會中斷到偵錯程式，此時cr3的值就是notepad的頁目錄基址，我們可以放心用cr3進行轉換啦。

後來轉念一想，虛擬位址到實體地址的轉換不就是根據頁目錄指標麼，可以通過cr3獲取，也可以直接從程序獲取。

!process命令就給出了basedir的值，直接通過此值進行轉換就ok了，經測試效果很好，媽媽再也不用擔心實體地址找不到了。

來自為知筆記(wiz)

原 線性位址到實體地址轉換後記

之前想手動查詢線性位址對應的實體地址，以更好的理解作業系統的分頁機制，cr3的值和指定程序的eprocess的值總是對不上。具體參考筆記 原 線性位址到實體地址轉換 今天突然靈光一閃，想起來張老師說過的關於cr3的相關知識，cr3是作業系統在切換程序的時候才會更新的，我們用.process p 指定...

關於線性位址到實體地址的轉換緩衝

為了能將線性位址快速地轉換到實體地址，tlb translation lookaside buffer 緩衝了當前經常被使用的線性位址對應的實體地址。多個cpu的tlb不需要進行同步，因為 不同cpu上執行的是不用的程序，也就是說他們相同的線性位址對應的實體地址是不同的，所以不需要進行同步。當cpu...

線性位址和實體地址

在保護模式下32位 還是採用段機制訪問記憶體 初始化臨時的要進入到ia 32e模式的gdt資料結構 label gdt64 dq 0x0000000000000000 label desc code64 dq 0x0020980000000000 label desc data64 dq 0x000...