成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

我去,又又又被內(nèi)存坑了!

存儲 存儲軟件
我看到網(wǎng)絡(luò)上很多文章介紹分段式內(nèi)存或者介紹段寄存器的時(shí)候就止步于此了,而事實(shí)上,進(jìn)入32位時(shí)代后,情況已經(jīng)發(fā)生了翻天覆地的變化,只講上面這一部分內(nèi)容實(shí)際上會誤導(dǎo)很多人。

大家好,我是你們的老朋友軒轅。

點(diǎn)進(jìn)這篇文章的朋友,恭喜你們,又要收獲新知識了~

這又是一篇非常硬核的技術(shù)文,建議配合一瓶怡寶或營養(yǎng)快線食用,效果更好哦。

很多小伙伴在學(xué)操作系統(tǒng)的時(shí)候,學(xué)習(xí)到內(nèi)存管理的部分時(shí),都會接觸到分段內(nèi)存管理、分頁內(nèi)存管理。

但很多人學(xué)完以后一頭霧水:

到底現(xiàn)在用的是分段還是分頁?

段寄存器這個(gè)東西現(xiàn)在還在用嗎?

為什么在講到虛擬地址翻譯的時(shí)候,好像跟段又沒有關(guān)系了呢?

之所有有這個(gè)問題,是因?yàn)楹芏嗤瑢W(xué)看的教程很多都是偏理論的或者是過時(shí)的,根本不給你講現(xiàn)代操作系統(tǒng)中實(shí)際的情況(關(guān)于這一點(diǎn)我已經(jīng)吐槽很多次了)。

今天軒轅就帶大家把內(nèi)存管理的這些疑問一次性弄清楚,分段還是分頁,別再傻傻分不清楚了!

Let's go!

在開始之前,我們還是先來簡單復(fù)習(xí)一下,操作系統(tǒng)書上講到的Intel x86 CPU架構(gòu)下的分段式內(nèi)存管理和分頁式內(nèi)存管理。

分段式內(nèi)存管理

早在16位的8086時(shí)代,CPU為了能尋址超過16位地址能表示的最大空間(64KB),引入了段寄存器。

通過將內(nèi)存空間劃分為若干個(gè)段,然后采用段基地址+段內(nèi)偏移的方式訪問內(nèi)存,這樣能訪問1MB的內(nèi)存空間了!

那時(shí)候,段寄存器有4個(gè),分別指向不同的段。

  • cs: 代碼段
  • ds: 數(shù)據(jù)段
  • ss: 棧段
  • es:擴(kuò)展段

在那個(gè)時(shí)候,段寄存器中存放的是段基地址,注意,是一個(gè)地址。

在通過ip寄存器讀取指令的時(shí)候,實(shí)際上是cs:ip,通過sp寄存器訪問棧的時(shí)候,實(shí)際上是ss:sp。

我看到網(wǎng)絡(luò)上很多文章介紹分段式內(nèi)存或者介紹段寄存器的時(shí)候就止步于此了,而事實(shí)上,進(jìn)入32位時(shí)代后,情況已經(jīng)發(fā)生了翻天覆地的變化,只講上面這一部分內(nèi)容實(shí)際上會誤導(dǎo)很多人。

變化1:

在32位時(shí)代,段寄存器又增加了兩個(gè):fs、gs,這兩個(gè)段寄存器有特殊用途。

變化2:

段寄存器里面存放的不再是段基地址,而是一個(gè)叫段選擇子的東西。注意,注意,一切的變化都從這里開始。

段寄存器是16位的寬度,原來這16位是個(gè)物理內(nèi)存地址,但現(xiàn)在,它是這樣一個(gè)結(jié)構(gòu):

實(shí)際上,現(xiàn)在的段寄存器中存放的是一個(gè)號碼,什么號碼呢?是一個(gè)表格中表項(xiàng)的號碼,這個(gè)表,有可能是全局描述符表GDT,也有可能是局部描述符表LDT。

那到底是哪個(gè)表?是由段選擇子從低到高的第三位來決定的,如果這一位是0,則是GDT,否則就是LDT。

那這兩個(gè)表又是啥,表里面裝的又是什么,怎么來尋址呢?

這兩個(gè)表的表項(xiàng)叫做段描述符,描述了一個(gè)內(nèi)存段的信息,比如段的基地址、最大長度、訪問屬性等等一系列信息,它長這個(gè)樣子:

CPU中單獨(dú)添置了兩個(gè)寄存器,用來指向這兩個(gè)表,分別是gdtr和ldtr。

在尋址的時(shí)候,CPU首先根據(jù)段寄存器中的號碼,通過gdtr或ldtr來到GDT/LDT中取出對應(yīng)的段描述符,然后再取出這個(gè)段的基地址,最后再結(jié)合段內(nèi)的偏移,完成內(nèi)存尋址。

也就是說,在16位模式下,段寄存器中直接就是一個(gè)地址,相當(dāng)于一個(gè)指針,而到了32位下,則變成了一個(gè)句柄,或者說二級指針了。

分頁式內(nèi)存管理

相比分段式內(nèi)存管理,可能大家對分頁式內(nèi)存管理要熟悉的多。

操作系統(tǒng)將內(nèi)存空間按照“頁”為單位劃分了很多頁面,這個(gè)頁的大小默認(rèn)是4KB(當(dāng)然可以改的),各進(jìn)程擁有虛擬的完整的地址空間,進(jìn)程中使用到的頁面會映射到真實(shí)的物理內(nèi)存上,程序中使用的地址是虛擬地址,CPU在運(yùn)行時(shí)自動將其翻譯成真實(shí)的物理地址。

既然要翻譯,那就得有地方記錄虛擬地址和物理地址的映射關(guān)系,只有根據(jù)這個(gè)關(guān)系,才能完成翻譯。

這個(gè)映射關(guān)系,是通過頁表來完成的。

頁表是用來記錄虛擬內(nèi)存頁面和物理內(nèi)存頁面之間的映射關(guān)系的,每一個(gè)頁表項(xiàng)記錄一個(gè)頁面的映射關(guān)系。但進(jìn)程的地址空間很大,這樣算下來需要的頁表項(xiàng)的數(shù)量也會非常多。而實(shí)際上進(jìn)程地址空間中很多頁面都沒有真正使用,也就沒有映射關(guān)系,這樣是一種浪費(fèi)。

為了解決這個(gè)問題,CPU引入了多級頁表的機(jī)制,在32位下一般是2級頁表,像下面這樣:

將虛擬地址劃分了三段:頁目錄索引、頁表索引、頁內(nèi)偏移。

線程切換時(shí),如果同時(shí)發(fā)生了進(jìn)程切換,CPU中的CR3寄存器將會加載當(dāng)前進(jìn)程的頁目錄地址。

在尋址的時(shí)候,通過CR3,一級一級按表索頁,最終找到對應(yīng)的物理內(nèi)存頁面,再結(jié)合頁面內(nèi)的偏移值,實(shí)現(xiàn)最終的內(nèi)存尋址。

現(xiàn)代操作系統(tǒng)實(shí)際情況

學(xué)完了這兩種內(nèi)存管理方式,很多人就要懵了:

現(xiàn)在操作系統(tǒng)到底用的哪種方式?好像是分頁,但為什么段寄存器好像還是有,到底是怎么一回事?

先說結(jié)論,答案就是:分段+分頁相結(jié)合的內(nèi)存管理方式

首先要明確一個(gè)前提,這一點(diǎn)非常非常重要:無論是分段還是分頁,這都是x86架構(gòu)CPU的內(nèi)存管理機(jī)制,這倆是同時(shí)存在的(保護(hù)模式下),并不是讓操作系統(tǒng)二選一!

既然是同時(shí)存在的,那為什么現(xiàn)在將內(nèi)存地址翻譯時(shí),都是講分頁,而很少談到分段呢?

這一切的一切,都是因?yàn)橐粋€(gè)原因:操作系統(tǒng)通過巧妙的設(shè)置,‘屏蔽’了段的存在。

操作系統(tǒng)怎么做到這一點(diǎn)的,接下來我們就來分析一下,徹底弄清楚背后的貓膩!

段寄存器

讓我們從段寄存器出發(fā),在Win7 32位系統(tǒng)上,使用調(diào)試器(我用的WinDbg)隨意調(diào)試一個(gè)程序,真的,隨意,記事本、瀏覽器、Word,你看上誰就調(diào)試誰。

在中斷的上下文中看一下,程序在執(zhí)行時(shí),段寄存器里面到底裝了啥?

來看下幾個(gè)主要的段寄存器的內(nèi)容:

  • cs: 001b
  • ds: 0023
  • ss: 0023
  • es: 0023

PS: 可能不同版本的Windows上面的結(jié)果不一樣,但這不重要,不影響我們分析問題。

只有0x001b和0x0023兩個(gè)值,前面我們說了,這不是一個(gè)地址,而是一個(gè)段選擇子,按照段選擇子的格式展開來看一下這兩個(gè)值指向的是哪個(gè)段描述符:

  1. 十六進(jìn)制:001b 
  2.  
  3. 二進(jìn)制:0000000000011 0 11 
  4.  
  5. 段序號:3 
  6.  
  7. 表類型:GDT 
  8.  
  9. 特權(quán)級:Ring3 
  1. 十六進(jìn)制:0023 
  2.  
  3. 二進(jìn)制:0000000000100 0 11 
  4.  
  5. 段序號:4 
  6.  
  7. 表類型:GDT 
  8.  
  9. 特權(quán)級:Ring3 

也就是說,cs段指向的是GDT中的第3個(gè)表項(xiàng),其他三個(gè)寄存器指向的是GDT中的第4個(gè)表項(xiàng)。

接下來,我們來看一下這個(gè)神秘的GDT里面的內(nèi)容到底是什么?很多人學(xué)了內(nèi)存管理,可能還從來沒看過真實(shí)的GDT里面到底是什么數(shù)據(jù)吧。

GDT是位于操作系統(tǒng)內(nèi)核地址空間中的,在Windows上有兩種查看方式,一種是通過Windbg,一種是通過一些ARK工具,我這里選擇使用PChunter這個(gè)神器進(jìn)行查看。

前面提到過,GDT中的表項(xiàng)是段描述符,這是一個(gè)比較復(fù)雜的數(shù)據(jù)格式,好在,這個(gè)神器對段描述符進(jìn)行了解析,使用表格字段的方式進(jìn)行了展示,讓我們看起來輕松多了。

廢話不多說了,來看一下這個(gè)神秘的GDT吧:

注意看第3個(gè)表項(xiàng)和第4個(gè)表項(xiàng)哦,看看它們的基地址,都是0x00000000。

再看它們的界限值,都是0x000FFFFF,注意看這個(gè)界限的單位,不是字節(jié),而是Page——頁,把這個(gè)值乘以頁面的大小4KB,就是0xFFFFF000。也就說這個(gè)段的上限到了0xFFFFF000這個(gè)頁面,再把這一個(gè)頁面的大小加進(jìn)去,就是0xFFFFFFFF了!

所以,重點(diǎn)來了!看到了嗎,GDT中的第3個(gè)和第4個(gè)表項(xiàng)所描述的這兩個(gè)段,它們的基地址都是0x00000000,整個(gè)段的大小都是0xFFFFFFFF,這意味著什么?這意味著整個(gè)進(jìn)程的地址空間實(shí)際上就是一個(gè)段!

也就是說:進(jìn)程的代碼段、數(shù)據(jù)段、棧段、擴(kuò)展段這四個(gè)段全部重合了,而且是整個(gè)進(jìn)程地址空間共計(jì)4GB成為了一個(gè)段。

說起來是分段,實(shí)際上等于沒分了,再加上段的基地址全部是0,那進(jìn)行地址翻譯的時(shí)候,有沒有段都沒什么區(qū)別了。

總結(jié)一句話:操作系統(tǒng)這樣分段,實(shí)際上是相當(dāng)于把段給架空了!

以上是Windows的情況,我們再來看一下Linux情況呢。

使用GDB隨意調(diào)試一個(gè)ELF32的可執(zhí)行文件,使用info r命令查看一下寄存器情況:

段寄存器有0x23和0x2b兩種情況:

  1. 十六進(jìn)制:0023 
  2. 二進(jìn)制:0000000000100 0 11 
  3. 段序號:4 
  4. 表類型:GDT 
  5. 特權(quán)級:Ring3 
  1. 十六進(jìn)制:002B 
  2. 二進(jìn)制:0000000000101 0 11 
  3. 段序號:5 
  4. 表類型:GDT 
  5. 特權(quán)級:Ring3 

Linux下我沒有找到可以直接用什么命令或者工具查看GDT的方式(如果你知道記得一定告訴我哦),于是去源代碼中尋找答案:

看到了嗎,這兩項(xiàng)所描述的段和Windows一樣,基地址為0,大小為4GB。

Windows和Linux都選擇了通過這種方式架空了CPU的分段內(nèi)存管理機(jī)制。

但需要說明一下的時(shí),雖然兩個(gè)操作系統(tǒng)都是這種情況,但并不意味著段機(jī)制徹底沒用到,CPU的任務(wù)管理TSS還是需要用到,這一點(diǎn)大家知道就行了。

64位情況

看到操作系統(tǒng)們都不待見這個(gè)分段式內(nèi)存管理,Intel似乎也感受到了這玩意確實(shí)很雞肋,于是到了64位平臺,徹底把段寄存器給打入了冷宮!

在Intel的指令手冊中,關(guān)于64位下的段寄存器是這樣描述的:

不管你的段寄存器中指向的段基址是什么內(nèi)容,都會被當(dāng)成0來對待。

這一下,分段內(nèi)存管理,徹底涼涼了···

總結(jié)

好了,最后來總結(jié)一下。

無論是分段還是分頁,這是CPU自身的機(jī)制,操作系統(tǒng)在管理內(nèi)存時(shí)繞不過去,但通過巧妙的分段內(nèi)存設(shè)計(jì),相當(dāng)于把分段的概念給屏蔽了,由此造成了我們平時(shí)在談?wù)撎摂M地址翻譯時(shí),忘記了段的存在,但不代表它真的不存在。

CPU硬件層面的工作必須是結(jié)合分段+分頁的內(nèi)存管理機(jī)制,操作系統(tǒng)是軟件繞不過去,所以采取了上面的方式應(yīng)付CPU了事。

從16位到32位再到如今普遍的64位,不同的時(shí)代,分段管理的實(shí)際情況都不一樣,大家在學(xué)習(xí)操作系統(tǒng)的時(shí)候一定不要死記硬背,而要結(jié)合實(shí)際情況哦。

現(xiàn)在分段和分頁,你弄清楚了嗎?

覺得有收獲的話,幫忙給軒轅分享轉(zhuǎn)發(fā)支持一下啊~

 

責(zé)任編輯:武曉燕 來源: 編程技術(shù)宇宙
相關(guān)推薦

2023-03-06 07:50:19

內(nèi)存回收Go

2022-11-18 07:34:12

Docker項(xiàng)目目錄

2020-03-31 16:02:23

戴爾

2023-07-18 19:11:21

配置信令系統(tǒng)

2024-04-10 08:39:56

BigDecimal浮點(diǎn)數(shù)二進(jìn)制

2020-09-29 07:57:48

設(shè)置HttpClientContent-Typ

2017-12-28 10:44:08

JavaScript瀏覽器網(wǎng)頁

2018-03-18 23:34:57

2014-07-23 10:19:02

小米4

2019-05-27 08:09:43

WiFi無線信道上網(wǎng)

2021-11-05 11:10:13

MyBatisSQL查詢

2011-08-31 08:41:07

Java高斯林

2019-11-11 13:40:45

Python 開發(fā)編程語言

2022-03-16 07:58:02

OOMdubbo內(nèi)存

2023-10-30 22:23:12

Cacherkube版本

2022-12-07 07:35:20

B站裁員隱情

2023-03-10 08:24:27

OOMdump線程

2020-12-19 10:46:20

黑客網(wǎng)絡(luò)安全網(wǎng)絡(luò)攻擊

2022-04-29 10:27:58

數(shù)據(jù)庫刪庫MySQL

2022-10-17 10:13:58

谷歌云游戲
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板: 性色av香蕉一区二区 | 久久精品小视频 | 成人欧美一区二区三区黑人孕妇 | 在线观看视频中文字幕 | 在线免费中文字幕 | 欧美精品一区二区在线观看 | 美女国产 | 中文字幕亚洲精品 | 久久首页 | 国产成人精品久久久 | 在线观看亚洲精品 | 日本中文字幕一区 | 精品在线一区二区三区 | 久久成人免费视频 | 日韩成人在线一区 | 欧美视频一区 | 久久成人精品视频 | 人人九九 | 久久99网 | 成人免费观看男女羞羞视频 | 精品久久精品 | 日本一区二区在线视频 | 精品自拍视频 | 精品久久亚洲 | 欧美日韩精品一区二区三区视频 | www.99热.com | 精品国产视频 | 天天曰夜夜操 | 国产精品 亚洲一区 | 欧美一级免费观看 | 日韩成人av在线 | 久久久久国产 | 精品一二三 | 国产精品久久久久久久久免费丝袜 | 免费成人高清在线视频 | 国产精品一区一区 | 久久精品视频在线免费观看 | 欧美色性 | 91视频在线看| 91精品国产91久久久久久密臀 | 日韩免费一区二区 |