linux gdt存放在什么位置

1. What is GDT在Protected Mode下，一个重要的必不可少的数据结构就是GDT（Global Descriptor Table）。

为什么要有GDT？我们首先考虑一下在Real Mode下的编程模型：

在Real Mode下，我们对一个内存地址的访问是通过Segment:Offset的方式来进行的，其中Segment是一个段的Base Address，一个Segment的最大长度是64 KB，这是16-bit系统所能表示的最大长度。而Offset则是相对于此Segment Base Address的偏移量。Base Address+Offset就是一个内存绝对地址。由此，我们可以看出，一个段具备两个因素：Base Address和Limit（段的最大长度），而对一个内存地址的访问，则是需要指出：使用哪个段？以及相对于这个段Base Address的Offset，这个Offset应该小于此段的Limit。当然对于16-bit系统，Limit不要指定，默认为最大长度64KB，而 16-bit的Offset也永远不可能大于此Limit。我们在实际编程的时候，使用16-bit段寄存器CS（Code Segment），DS（Data Segment），SS（Stack Segment）来指定Segment，CPU将段积存器中的数值向左偏移4-bit，放到20-bit的地址线上就成为20-bit的Base Address。

到了Protected Mode，内存的管理模式分为两种，段模式和页模式，其中页模式也是基于段模式的。也就是说，Protected Mode的内存管理模式事实上是：纯段模式和段页式。进一步说，段模式是必不可少的，而页模式则是可选的——如果使用页模式，则是段页式；否则这是纯段模式。

既然是这样，我们就先不去考虑页模式。对于段模式来讲，访问一个内存地址仍然使用Segment:Offset的方式，这是很自然的。由于 Protected Mode运行在32-bit系统上，那么Segment的两个因素：Base Address和Limit也都是32位的。IA-32允许将一个段的Base Address设为32-bit所能表示的任何值（Limit则可以被设为32-bit所能表示的，以2^12为倍数的任何指），而不象Real Mode下，一个段的Base Address只能是16的倍数（因为其低4-bit是通过左移运算得来的，只能为0，从而达到使用16-bit段寄存器表示20-bit Base Address的目的），而一个段的Limit只能为固定值64 KB。另外，Protected Mode，顾名思义，又为段模式提供了保护机制，也就说一个段的描述符需要规定对自身的访问权限（Access）。所以，在Protected Mode下，对一个段的描述则包括3方面因素：[Base Address, Limit, Access]，它们加在一起被放在一个64-bit长的数据结构中，被称为段描述符。这种情况下，如果我们直接通过一个64-bit段描述符来引用一个段的时候，就必须使用一个64-bit长的段积存器装入这个段描述符。但Intel为了保持向后兼容，将段积存器仍然规定为16-bit（尽管每个段积存器事实上有一个64-bit长的不可见部分，但对于程序员来说，段积存器就是16-bit的），那么很明显，我们无法通过16-bit长度的段积存器来直接引用64-bit的段描述符。

怎么办？解决的方法就是把这些长度为64-bit的段描述符放入一个数组中，而将段寄存器中的值作为下标索引来间接引用（事实上，是将段寄存器中的高13 -bit的内容作为索引）。这个全局的数组就是GDT。事实上，在GDT中存放的不仅仅是段描述符，还有其它描述符，它们都是64-bit长，我们随后再讨论。

GDT可以被放在内存的任何位置，那么当程序员通过段寄存器来引用一个段描述符时，CPU必须知道GDT的入口，也就是基地址放在哪里，所以Intel的设计者门提供了一个寄存器GDTR用来存放GDT的入口地址，程序员将GDT设定在内存中某个位置之后，可以通过LGDT指令将GDT的入口地址装入此积存器，从此以后，CPU就根据此积存器中的内容作为GDT的入口来访问GDT了。

GDT是Protected Mode所必须的数据结构，也是唯一的——不应该，也不可能有多个。另外，正象它的名字（Global Descriptor Table）所揭示的，它是全局可见的，对任何一个任务而言都是这样。

在Ubuntu中安装了JDK就不用再安装JRE了，如安装了JRE，再安装JDK会重新再装一个JRE。打开Ubuntu终端，使用命令：

sudo

apt-get

install

sun-java6-jre

//安装jre

sudo

apt-get

install

sun-java6-jdk

//安装jdk

让终端的当前目录为想要安装Eclipse的目录，本人安装在/usr/share

目录下，

可以通过在想要安装Eclipse的目录下打开终端，这时终端的当前目录就是我们要安装的目录了。

sudo

tar

-zxvf

/PATH/eclipse-SDK-3.7.1-linux-gtk.tar.gz

将PATH替换成eclipse压缩包存放的目录，这时eclipse就会解压缩到终端的当前目录了。

添加Eclipse桌面快捷方式

在Ubuntu桌面或Linuxmint桌面，应用程序的编程菜单中添加Eclipse快捷方式图标：

sudo

gedit

/usr/share/applications/eclipse.desktop

/usr/share/applications/

目录下有很多到快捷方式图标，可以将它们拖到桌面，这样就可以直接在桌面打开相应的程序了。

在Gedit打开的文件中加入下面的代码：

[Desktop

Entry]

Encoding=UTF-8

Name=Eclipse

Comment=Eclipse

IDE

#改成自己安装Eclipse可执行文件的目录路径

Exec=/usr/share/eclipse/eclipse

#改成自己的Eclipse

图标路径

Icon=/usr/share/eclipse/icon.xpm

Terminal=false

StartupNotify=true

Type=Application

#类别：应用程序编程IDEJava

Categories=ApplicationDevelopmentIDEJava

Linux内核采用页式存储管理。虚拟地址空间划分成固定大小的“页面”，由MMU在运行时将虚拟地址“映射”成（或者说变换成）某个物理内存页面中的地址。与段式存储管理相比，页式存储管理有很多好处。首先，页面都是固定大小的，便于管理。更重要的是，当要将一部分物理空间中的内容换出到磁盘上的时候，在段式存储管理中要将整个段（通常都很大）都换出，而在页式存储管理中则是按页进行，效率显然要高得多。页式存储管理与段式存储管理所要求的硬件支持不同，一种CPU既然支持页式存储管理，就无需再支持段式存储管理。但是，i386的情况是特殊的。由于i386系列的历史演变过程，它对页式存储管理的支持是在其段式存储管理已经存在了相当长的时间以后才发展起来的。所以，不管程序是怎样写的，i386 CPU一律对程序中使用的地址先进行段式映射，然后才能进行页式映射。既然CPU的硬件结构是这样，Linux内核也只好服从Intel的选择。这样的双重映射其实是毫无必要的，也使映射的过程变得不容易理解，以至有人还得出了Linux采用“段页式”存储管理技术这样一种似是而非的结论。Linux内核所采取的办法是使段式映射的过程实际上不起作用（除特殊的VM86模式外，那是用来模拟80286的）。

Linux内核中只使用四种不同的段寄存器数值，两种用于内核本身，两种用于所有的进程：

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

__KERNEL_CS 0x100 0 0 0 0 0 0 0 0 0 0 1 0 | 0 | 0 0

__KERNEL_DS 0x180 0 0 0 0 0 0 0 0 0 0 1 1 | 0 | 0 0

__USER_CS 0x230 0 0 0 0 0 0 0 0 0 1 0 0 | 0 | 1 1

__USER_DS 0x280 0 0 0 0 0 0 0 0 0 1 0 1 | 0 | 1 1

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

按照Intel对段寄存器的定义我们可以看出这四个段地址描述符都使用GDT表，再结合linux初始化时设置的GDT表的内容（全局段地址描述符表）我们可以知道他们所描述的段都是从0地址到4GB的整个32位地址空间，也就是说经过这些段地址描述符映射后的地址与映射前保持原值不变。所以说实际上Linux根本没有使用80386以上CPU所提供的段式存储管理机制。

它们之间的唯一区别就是内核态的优先级是0，而用户态的优先级是3。

---