有关段式映射的问题

sherf

回复  sherf

你想问什么？我在１１楼还没说明白吗？
tempname3 发表于 2011-04-28 17:20

对于1，我要说的是实现，即段式管理实现的步骤（大致步骤即可，不是代码级别的）

对于2，有关页式映射部分，我重新review了一下，是我之前理解上有偏差了。 0x8048368是一个线性地址，当它经过线性转换（高10位，中间10位，低12位）后，所得到的 0x740368 是一个物理地址，而且该地址不是逻辑偏移（无需与段基址关联），即 greeting() 的物理地址就是 0x740368。

对于你所说的“linux一般不用LDT，CS都一样（除了user/kernel之间的转换）“，我的理解具体如下：

如果我在命令行输入 greeting（假设编译后的名字叫greeting），则系统会加载greeting入内存。这时，我在另一个命令窗口，再键入greeting，则系统会再加载一次 greeting。则后一个greeting 的内存映像会覆盖第一次加载的greeting内存映像。原因是因为它们的线性地址都是 0x8048368，最终转换出来的结果都是 0x740368（这个我下面会解释，不是这样的）。

但在linux的运行中是不会出现这种覆盖现象的，即第一次greeting的物理地址如果是 0x740368，则第二次的greeting的物理地址就一定不是 0x740368。那是什么原因造成线性地址一样而翻译结果不一样呢？我觉得是 页目录首址，即赋予 CR3 的那个地址。那换句话说，第一次greeting使用的页表与第二次greeting 使用的页表不一样，是2套不同的页表，且这2套页表应该是放在内核空间里的（猜的，还没看代码）。而linux之所以能够不用LDT（另外为每个进程设定不同的段基址）就能“有效隔离“不同的进程、使它们不重叠，靠的也是这个（一套不同的页表，至少页首址不同）。

我的理解对吗？如果是对的，那在i386中，linux的段式管理到底作了什么？因为通过上面的分析（如果上面的分析是对的话），可以看出，段基址、段界限等信息在寻址中根本不会用到，那是否只是为了检查权限（即DPL，RPL等信息）？

tempname3

回复 21# sherf

你的理解有对有错，对的是每个进程有自己的页表，分页单元根据页表翻译线性地址，于是每个进程有自己独立的地址空间。错的是代编译后出现的地址从概念上来说不是线性地址，而是逻辑地址中的offset，另外base,limit都用到了，只不过用了等于没用。

sherf

回复  sherf

你的理解有对有错，对的是每个进程有自己的页表，分页单元根据页表翻译线性地址，于是每个 ...
tempname3 发表于 2011-04-28 17:36

-----------------------------------------------------
摘自精华贴（内核吧里的，你之前也提到的）：http://bbs.chinaunix.net/thread-2083672-1-1.html

2、CPU段式内存管理，逻辑地址如何转换为线性地址

.....

首先，给定一个完整的逻辑地址[段选择符：段内偏移地址]，
1、看段选择符的T1=0还是1，知道当前要转换是GDT中的段，还是LDT中的段，再根据相应寄存器，得到其地址和大小。我们就有了一个数组了。
2、拿出段选择符中前13位，可以在这个数组中，查找到对应的段描述符，这样，它了Base，即基地址就知道了。
3、把Base + offset，就是要转换的线性地址了。

......

-----------------------------------------------------


如果“精华帖“上说的没错的话那在 i386CPU 里，linux对于段式映射的处理就不是可有可无了，而是必须要进行段式映射了。因为在 objdump 得出的 greeting()的地址 0x8048368 是一个逻辑地址，它需要经过段式映射才能转换成线性地址，即按照“精华帖“的内容，线性地址 = Base + offset，其中，offset 是 0x8048368，Base是段地址，这需要经过段式映射处理后才可以知道 greeting 的段基址是多少。因此，不太明白linux的段式管理只是走形式的说法，它不是应该是一个必要的步骤吗？至少需要取得段地址？且，到底这个段地址该如何取还真不知道，因为在linux里似乎没有LDT，只是通过不同进程使用不同页表而对各个进程进行隔离，难道是取该进程的页目录首址（赋予CR3的那个值）作为段基址（即Base）而进行段式映射？

mnf

-----------------------------------------------------
摘自精华贴（内核吧里的，你之前也提到的）： ...
sherf 发表于 2011-04-28 18:01

    你怎么还是 segment 和 page 混在一起说呀，你先把这个错误改正了再说。

否则不想再和你扯了

sherf

你怎么还是 segment 和 page 混在一起说呀，你先把这个错误改正了再说。

否则不想再和你扯了
mnf 发表于 2011-04-28 18:22

nmf，这次是你搞混了吧？
   
逻辑地址 -> 段式映射 -> 线性地址 -> 页式映射 -> 物理地址

上面的逻辑地址就是 base：offset。而线性地址 = base + offset。不太清楚你说的“你怎么还是 segment 和 page 混在一起说呀“是从哪里来的？

tempname3

回复 23# sherf


唉，我把你那个例子描述一遍吧。

指令里出现的0x8048368就是逻辑地址的offset部分。此刻这个offset所位于的段的描述符（里面有base,limit,权限等信息）在GDT里，而某个段寄存器（CS或DS或其它）的高位用作索引在GDT里取出这个段的描述符，继而就可以得到它的base，base与offset相加，便得到了线性地址，线性地址再经分页单元根据当前页表的内容翻译成物理地址。但是Linux下每个进程在用户态下用的都是同一对段描述符（代码段和数据段），或者所有进程的用户态的cs与ds都是同一个值（继而指向GDT里的同两项）；内核态的情况也是如此。这个段描述符说，此段base为０，limit为4G-1。继而base+offset = offset，也就是说，逻辑地址转换为线性地址后没有任何变化！分段和分页在功能上有重复的地方，一般用分页就够了。Linux之所以这样做是因为CPU非得走分段这个流程。这样做的结果就是，分段在地址转换过程中没有起到任何作用，只是走走过场而已。真正让进程有独立地址空间（同一个地址在不同进程里指向不同物理单元，互不影响）是由分页机制完成的。所以不要再纠结段的概念了，更不用说LDT了。

0x8048368（逻辑地址的offset）被翻译成物理地址的过程为：根据CS或DS值的高位，在GDT里找到段描述符，取其base(为０)，将其与0x8048368相加（结果还为0x8048368,线性地址），然后送到分页单元。分页单元根据当前页表的内容，将其翻译成物理地址，然后送到总线上。

mnf

回复 25# sherf


>>>    ，难道是取该进程的页目录首址（赋予CR3的那个值）作为段基址（即Base）而进行段式映射？
你说呢，是不是还在混淆呀

sherf

回复  sherf


>>>    ，难道是取该进程的页目录首址（赋予CR3的那个值）作为段基址（即Base）而进行段 ...
mnf 发表于 2011-04-28 18:38

我前面还有话的，别只截取这几个字.....

mnf

我前面还有话的，别只截取这几个字.....
sherf 发表于 2011-04-28 18:50

不用了， 光凭这句话，就知道你还不懂 segmentation 和 paging 的区别

sherf

不用了， 光凭这句话，就知道你还不懂 segmentation 和 paging 的区别
mnf 发表于 2011-04-28 18:53

我真搞不明白你想说什么......

我的原话是这样的：

......且，到底这个段地址该如何取还真不知道，因为在linux里似乎没有LDT，只是通过不同进程使用不同页表而对各个进程进行隔离，难道是取该进程的页目录首址（赋予CR3的那个值）作为段基址（即Base）而进行段式映射？

nmf, 具体你自己判断吧.........