14.8.1 运行Bochs调试程序
我们假设Bochs系统已被安装在目录“C:\Program Files\Bochs-2.1.1\”中，并且Linux 0.11系统的Bochs配置文件名称是bochsrc-hd.bxrc。现在在包含内核Image文件的目录下建立一个简单的批处理文件run.bat，其内容如下：

"C:\Program Files\Bochs-2.1.1\bochsdbg" -q -f bochsrc-hd.bxrc

其中bochsdbg是Bochs系统的调试执行程序。运行该批处理命令即可进入调试环境。此时Bochs的主显示窗口空白，而控制窗口将显示以下类似内容：

C:\Documents and Settings\john1\桌面\Linux-0.11>"C:\Program Files\Bochs-2.1.1\bo
chsdbg" -q -f bochsrc-hd.bxrc
========================================================================
                      Bochs x86 Emulator 2.1.1
                          February 08, 2004
========================================================================
00000000000i[     ] reading configuration from bochsrc-hd.bxrc
00000000000i[     ] installing win32 module as the Bochs GUI
00000000000i[     ] Warning: no rc file specified.
00000000000i[     ] using log file bochsout.txt
Next at t=0
(0) context not implemented because BX_HAVE_HASH_MAP=0
[0x000ffff0] f000:fff0 (unk. ctxt): jmp f000:e05b             ; ea5be000f0
<bochs:1>

此时Bochs调试系统已经准备好开始运行，CPU执行指针已指向ROM BIOS中地址0x000fffff0处的指令处。其中'<bochs:1>'是命令输入提示符，其中的数字表示当前的命令序列号。在命令提示符'<bochs:1>'后面键入'help'命令，可以列出调试系统的基本命令。若要了解某个命令的具体使用方法，可以键入'help'命令并且后面跟随一个用单引号括住的具体命令，例如：“help 'vbreak'”，如下面所示。

<bochs:1> help
help - show list of debugger commands
help 'command'- show short command description
-*- Debugger control -*-
   help, q|quit|exit, set, instrument, show, trace-on, trace-off,
   record, playback, load-symbols, slist
-*- Execution control -*-
   c|cont, s|step|stepi, p|n|next, modebp
-*- Breakpoint management -*-
   v|vbreak, lb|lbreak, pb|pbreak|b|break, sb, sba, blist,
   bpe, bpd, d|del|delete
-*- CPU and memory contents -*-
   x, xp, u|disas|disassemble, r|reg|registers, setpmem, crc, info, dump_cpu,
   set_cpu, ptime, print-stack, watch, unwatch, ?|calc
<bochs:2> help 'vbreak'
help vbreak
vbreak seg:off - set a virtual address instruction breakpoint
<bochs:3>

为了让Bochs直接模拟执行到Linux的引导启动程序开始处，我们可以先使用断点命令在0x7c00处设置一个断点，然后让系统连续运行到0x7c00处停下来。执行的命令序列如下：

<bochs:3> vbreak 0x0000:0x7c00
<bochs:4> c
(0) Breakpoint 1, 0x7c00 (0x0:0x7c00)
Next at t=4409138
(0) [0x00007c00] 0000:7c00 (unk. ctxt): mov ax, 0x7c0             ; b8c007
<bochs:5>

此时，CPU执行到boot.s程序开始处的第1条指令处，Bochs主窗口将显示出“Boot From floppy...”等一些信息。现在，我们可以利用单步执行命令's'或'n'（不跟踪进入子程序）来跟踪调试程序了。在调试时可以使用Bochs的断点设置命令、反汇编命令、信息显示命令等来辅助我们的调试操作。下面是一些常用命令的示例：

<bochs:8> u /10                                    # 反汇编从当前地址开始的10条指令。
00007c00: (                    ): mov ax, 0x7c0             ; b8c007
00007c03: (                    ): mov ds, ax                ; 8ed8
00007c05: (                    ): mov ax, 0x9000            ; b80090
00007c08: (                    ): mov es, ax                ; 8ec0
00007c0a: (                    ): mov cx, 0x100             ; b90001
00007c0d: (                    ): sub si, si                ; 29f6
00007c0f: (                    ): sub di, di                ; 29ff
00007c11: (                    ): rep movs word ptr [di], word ptr [si] ; f3a5
00007c13: (                    ): jmp 9000:0018             ; ea18000090
00007c18: (                    ): mov ax, cs                ; 8cc8
<bochs:9> info r                                  # 查看当前CPU寄存器的内容
eax            0xaa55           43605
ecx            0x110001         1114113
edx            0x0              0
ebx            0x0              0
esp            0xfffe           0xfffe
ebp            0x0              0x0
esi            0x0              0
edi            0xffe4           65508
eip            0x7c00           0x7c00
eflags         0x282            642
cs             0x0              0
ss             0x0              0
ds             0x0              0
es             0x0              0
fs             0x0              0
gs             0x0              0
<bochs:10> print-stack                            # 显示当前堆栈的内容
  0000fffe [0000fffe]  0000
  00010000 [00010000]  0000
  00010002 [00010002]  0000
  00010004 [00010004]  0000
  00010006 [00010006]  0000
  00010008 [00010008]  0000
  0001000a [0001000a]  0000
...
<bochs:11> dump_cpu                               # 显示CPU中的所有寄存器和状态值。
eax:0xaa55
ebx:0x0
ecx:0x110001
edx:0x0
ebp:0x0
esi:0x0
edi:0xffe4
esp:0xfffe
eflags:0x282
eip:0x7c00
cs:s=0x0, dl=0xffff, dh=0x9b00, valid=1
ss:s=0x0, dl=0xffff, dh=0x9300, valid=7
ds:s=0x0, dl=0xffff, dh=0x9300, valid=1
es:s=0x0, dl=0xffff, dh=0x9300, valid=1
fs:s=0x0, dl=0xffff, dh=0x9300, valid=1
gs:s=0x0, dl=0xffff, dh=0x9300, valid=1
ldtr:s=0x0, dl=0x0, dh=0x0, valid=0
tr:s=0x0, dl=0x0, dh=0x0, valid=0
gdtr:base=0x0, limit=0x0
idtr:base=0x0, limit=0x3ff
dr0:0x0
dr1:0x0
dr2:0x0
dr3:0x0
dr6:0xffff0ff0
dr7:0x400
tr3:0x0
tr4:0x0
tr5:0x0
tr6:0x0
tr7:0x0
cr0:0x60000010
cr1:0x0
cr2:0x0
cr3:0x0
cr4:0x0
inhibit_mask:0
done
<bochs:12>

由于Linux 0.11内核的32位代码是从绝对物理地址0处开始存放的，因此若想直接执行到32位代码开始处，即head.s程序开始处，我们可以在线性地址0x0000处设置一个断点并运行命令'c'执行到那个位置处。
另外，当直接在命令提示符下打回车键时会重复执行上一个命令；按向上方向键会显示上一命令。其他命令的使用方法请参考'help'命令。

14.8.2 定位内核中的变量或数据结构
在编译内核时会产生一个system.map文件。该文件列出了内核Image (bootimage)文件中全局变量和各个模块中的局部变量的偏移地址位置。在内核编译完成后可以使用前面介绍的文件导出方法把system.map文件抽取到主机环境（windows）中。有关system.map文件的详细功能和作用请参见2.10.3节。system.map样例文件中的部分内容见如下所示。利用这个文件，我们可以在Bochs调试系统中快速地定位某个变量或跳转到指定的函数代码处。

...
Global symbols:

 _dup: 0x16e2c
 _nmi: 0x8e08
 _bmap: 0xc364
 _iput: 0xc3b4
 _blk_dev_init: 0x10ed0
 _open: 0x16dbc
 _do_execve: 0xe3d4
 _con_init: 0x15ccc
 _put_super: 0xd394
 _sys_setgid: 0x9b54
 _sys_umask: 0x9f54
 _con_write: 0x14f64
 _show_task: 0x6a54
 _buffer_init: 0xd1ec
 _sys_settimeofday: 0x9f4c
 _sys_getgroups: 0x9edc
...

同样，由于Linux 0.11内核的32位代码是从绝对物理地址0处开始存放的，system.map中全局变量的偏移位置值就是CPU中线性地址位置，因此我们可以直接在感兴趣的变量或函数名位置处设置断点，并让程序连续执行到指定的位置处。例如若我们想调试函数buffer_init()，那么从system.map文件中可以知道它位于0xd1ec处。此时我们可以在该处设置一个线性地址断点，并执行命令'c'让CPU执行到这个指定的函数开始处，见如下所示。

<bochs:12> lb 0xd1ec                              # 设置线性地址断点。
<bochs:13> c                                      # 连续执行。
(0) Breakpoint 2, 0xd1ec in ?? ()
Next at t=16689666
(0) [0x0000d1ec] 0008:0000d1ec (unk. ctxt): push ebx                  ; 53
<bochs:14> n                                      # 执行下一指令。
Next at t=16689667
(0) [0x0000d1ed] 0008:0000d1ed (unk. ctxt): mov eax, dword ptr ss:[esp+0x8] ; 8b442408
<bochs:15> n                                      # 执行下一指令。
Next at t=16689668
(0) [0x0000d1f1] 0008:0000d1f1 (unk. ctxt): mov edx, dword ptr [ds:0x19958] ; 8b1558990100
<bochs:16>

程序调试是一种技能，需要多练习才能熟能生巧。上面介绍的一些基本命令需要组合在一起使用才能灵活地观察到内核代码执行的整体环境情况。

Bochs使用简单教程 
Bochs是一个开源的虚拟机。它可以实现vpc和vmware的大部分功能。你也可以像使用vmware一样的在Bochs里面安装操作系统。但是，由于它是全模拟的。所以，速度要远远慢于vmware.这样看来Bochs好像没有什么优势.是这样吗？在应用方面的确如此。

但是,在其他一个方面它是处于绝对优势的。那就是它具有调试功能!这是一个让人振奋的功能。这个功能在你调试操作系统或者其他一些在裸机上运行的程序时候，会让你有一种在写windows下运行的应用程序的感觉。有时候它是我们的救命稻草。没了它，也能活，但是肯定要糟糕的多。好了我们开始切入正题。

一、 配置Bochs 
实际上配置Bochs是很简单的，为什么很多人不会配置呢？我觉的就是因为他使用和配置方式和普通程序不一样——配置文件。实际上配置文件是和ini文件、bat文件类似的。Bochs没有给我们提供图形界面的配置工具。这就需要我们自己来修改配置文件。

简单的配置就可以让你的操作系统在Bochs里面跑起来。用Bochs跑完整的linux和windows是不现实的。实在是太慢了。一般我们也只能把他当成调试器来使用。现在，我们先看一下如何让dos在他里面跑起来。如果你细心的话你会发现在Bochs文件夹里面有一个Bochsrc-sample.txt的文本文件。里面包含了所有了Bochs参数的信息。这个是官方的教程。可惜是英文的，而且我也没有找到有中文的教程（不然也没有我这篇文章）。在这里我们仅仅介绍最简单的配置选项。好了，废话就不多说了。我们现在就开始。 
我们以一个例子来说明，这个例子是我用来跑dos以及我自己的小操作系统的。下面就是我们要用到的最基本的选项： 
# 在一行的最前面加上“#”表示这一行是注释行。 
# 内存，以MB为单位，对于dos来说最大可以访问16MB 
# 的内存，所以我就给了他16MB，你可以根据自己的机器来调整 
megs: 16 
# 下面两句一般是不可以改的，至于干什么用的就不用我说 
# 了。从他们的文件名就可以看出来。 
romimage: file=../BIOS-Bochs-latest, address=0xf0000 
vgaromimage: file=../VGABIOS-lgpl-latest 
# 这个还用说吗？当然是软驱了，我想我们写操作系统肯定是先 
# 把操作系统放在软盘（或映像）里面吧？在Bochs里面是可 
# 以使用任意大小的软驱映像的。可以是1.44或2.88，我一般使 
# 用2.88。还有就是Bochs里面可以使用两个软驱。不过好像 
# 我们并不经常这样做。 
floppya: 2_88=test.img, status=inserted 
#floppyb: 1_44=floppyb.img, status=inserted 
# 下面是硬盘，很简单，还有就是Bochs也是可以支持多个硬 
# 盘的。那么，硬盘文件是怎么生成的呢？我们可以发现硬盘是 
# img格式的。你注意没有在Bochs文件夹里有一个工具叫 
# bximage.exe，我想你应该猜出来了。他就是用来生成这个硬盘 
# 文件的工具。我在这儿还想说的是硬盘分三种格式的，最好选 
#用growing类型。这种有一个好处就是节省硬盘空间，不过使用 
#这种类型的硬盘还需要在下面加上mode = growing这个选项。 
ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 
ata0-master: type=disk, path="dos.img", cylinders=306, heads=4, spt=17 
# 下面这个就是光驱，没什么好说的。如果你想使用物理光驱， 
# 只要让path=E:（我们假设E盘是光驱） 
ata0-slave: type=cdrom, path="dos.iso", status=inserted 
# 这个是启动设备，可以使用cdrom（光驱）、c（硬盘）或floppy（软 
# 驱）。 
#boot: cdrom 
boot: c 
#boot: floppy 
# 这一句可以不要，他只是指定用来保存日志的文件。如果不指定的 
# 话他就会输出到命令控制台上。 
log: Bochsout.txt 
# 这一句是设置在开机时是否激活鼠标，Bochs对于鼠标的控制不是# 很好。建议如果不是特别需要的话不要激活他。在运行期间也可以点窗口右上角的鼠标图标来激活他。 
mouse: enabled=0 
以上这些设置就可以让你的DOS或自己的小操作系统在Bochs里面跑起来了。至于其他的一些高级支持，你可以查看Bochsrc-sample.txt里面的说明。不要害怕他，其实很简单。关键是抛弃恐惧。

二、 启动Bochs 
配置文件已经写好了，硬盘文件等也都已经弄好了。那么我们如何来启动Bochs呢？很简单，你右击一下上面写的那个配置文件（例如myos.bxrc，注意：扩展名要是.bxrc。）选择“运行”或双击即可。不过我一般都不这样做，我一般是写一个批处理文件。

很简单，如下所示： 
cd "d:\Bochs-2.2.1\dos" 
..\Bochs.exe -q -f Bochsrc.bxrc 
这样做的好处就是无论这个启动脚本放在哪儿都是可以使用的。那么，我们如何进入调试状态呢？下面我们就来讨论这个问题。

三、 调试功能 
新建一个批处理文件，写入一下内容： 
cd "d:\Bochs-2.2.1\dos" 
..\Bochsdbg.exe -q -f Bochsrc.bxrc 
运行这个批处理文件，你就可以进入调试状态了。不过你会发现，程序卡住了。没有想普通运行状态一样进入你的dos操作系统。为什么？因为调试在等待你的命令。你只有给他一个命令他才会继续。我们输入“c”，然后回车。是不是dos已经可是运行了？

如果没有运行说明你输入的窗口不对，你不会把c输入到那个没有光标的窗口了吧？如果真是那样我真是服了你了。真的！但是，dos运行起来了，如何在返回调试状态？很简单，按ctrl+c。什么你正在运行的程序被结束了？谁让你在操作系统窗口中按了，我是说在调试窗口按。至于哪个是调试窗口，哪个是操作系统窗口，我就不说了。如果你不知道你就干脆别使用Bochs了，也不要写什么程序了，更不要开发什么操作系统了。为什么？因为你不可能成功。从这儿就可以看出来。最好是找块豆腐撞死，这样你会很幸福的死去，不然你就会成为教育后代的典范——看到了吗XXX是怎么死的，笨死的。呵呵！开个玩笑。你真要不知道 
千万不要来找我，找我我也不告诉你。不好意思，我也不知道。那么，在调试状态下我们可以干哪些事呢？你用过debug吗？它能做的Bochs都能做，它不能做的Bochs也可以做。下面就是一些常用的调试命令。

help

我最想告诉大家的是这个指令，因为他可以告诉我们一切。古语说：“授之以鱼，不若授之以渔”。我觉的很有道理。但是，有些人就是不想学这种一劳永逸的方法。所以，我还要继续写下去。 
输入help，回车。你会得到以下信息： 
help - show list of debugger commands 
help 'command'- show short command description 
-*- Debugger control -*- 
help, q|quit|exit, set, instrument, show, trace-on, trace-off, 
record, playback, load-symbols, slist 
-*- Execution control -*- 
c|cont, s|step|stepi, p|n|next, modebp 
-*- Breakpoint management -*- 
vb|vbreak, lb|lbreak, pb|pbreak|b|break, sb, sba, blist, 
bpe, bpd, d|del|delete 
-*- CPU and memory contents -*- 
x, xp, u|disas|disassemble, r|reg|registers, setpmem, crc, info, dump_cpu, 
set_cpu, ptime, print-stack, watch, unwatch, ?|calc 
需不需要我翻译一下前两句？那好吧。 
help － 现实调试命令列表 
help '命令' － 显示某条命令的详细用法。 
命令分为哪些？很明显，四类：调试控制，运行控制，断点管理，CPU和内存控制。我不想在这儿一一介绍了。没有必要，我只介绍一下最常用的就可以了。 
c：继续，前面我们已经用过了。 
s：单步执行。他还有一个扩展用法。 
s n ：执行n步。 
b 0x7c00：在内存0x7c00处设置一个断点.当程序执行到0x7c00处就自动进入到调试状态.后面的这个数指的是内存的线性地址

。也可以使用10进制的数，但是好像没有人会这样做。 
x /20 0x7c00: 以16进制的形式从内存的0x7c00开始显示20个字的数据。这个是很常用的命令，但是需要注意的是他的显示顺序和16进制编辑器中的显示顺序有一点小的区别。他的显示是以字为单位的，而且在字中是从低到高显示的.不过也没有什么大不了的。你只要稍微注意一下就可以了。

dump_cpu：这个是我最长用的三个指令之一。他的功能是显示现在的寄存器的状态，详细内容类似于： 
eax:0x00000000, ebx:0x00000000, ecx:0x00000000, edx:0x00000683 
ebp:0x00000000, esp:0x00000000, esi:0x00000000, edi:0x00000000 
eip:0x0000fff0, eflags:0x00000002, inhibit_mask:0 
cs:s=0xf000, dl=0x0000ffff, dh=0xff009bff, valid=1 
ss:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1 
ds:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1 
es:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1 
fs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1 
gs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1 
ldtr:s=0x0000, dl=0x00000000, dh=0x00000000, valid=0 
tr:s=0x0000, dl=0x00000000, dh=0x00000000, valid=0 
gdtr:base=0x00000000, limit=0xffff 
idtr:base=0x00000000, limit=0xffff 
dr0:0x00000000, dr1:0x00000000, dr2:0x00000000 
dr3:0x00000000, dr6:0xffff0ff0, dr7:0x00000400 
cr0:0x00000010, cr1:0x00000000, cr2:0x00000000 
cr3:0x00000000, cr4:0x00000000 
u /20 0x7c00 :反汇编内存0x7c00处，反汇编的长度是20。你想不想知道dos的引导程序是什么样子的？执行一下这个命令就可以了。你还可以使用这样的命令 u /20 cs:0x120a，至于什么意思，我也不说了。

现在，我们已经介绍了6条命令了。够了。对于日常应用已经完全够用了。如果你想了解其他命令的用法只要执行一下help “命令名”就可以了（注意，命令上要带有引号）。好了。现在已经把Bochs的基本功能介绍完了。你是不是感觉Bochs很简单？对于简单的应用来说，确实如此。但是，想让他支持一些高级功能就有点麻烦了。毕竟它是全模拟的虚拟机，所以在有些方面实现起来并不容易。但是，向网络之类的功能还是可以支持的。你只要看一下Bochsrc-sample.txt就知道了。我在这儿就不说了。我还要说的是Bochs不仅仅可以调试操作系统，还可以调试dos下的程序。我们知道dos没有多少好的调试器。那么我们完全可以使用Bochs来调试。你知道在程序的开头输出一下程序的段地址和偏移地址，然后暂定一下，在虚拟机里面设置一下断点就可以了。我一般都是在在程序里面潜入一句汇编： 
jmp $ 
这样在程序死循环的时候在调试窗口按下ctrl+c就可以看到他的段地址和偏移地址了。然后，在去掉这一句，设置一下断点，运行这个程序。是不是在指定位置中断了？

一：配置
bochs.exe是执行模式，不能调试的。Bochs的调试工具是Bochsdbg.exe。同样，调试的时候你仍然需要进行配置。此时如果我们还使用双击.bxrc配置文件的方法显然是不行的（因为此时会运行Bochs.exe而不是Bochsdbg.exe）。所以我copy了《自己动手写操作系统》作者于渊的方法——使用bat批处理文件。
新建一个批处理文件然后进行编辑。以下内容为我的bat文件：
D:\Develop\Bochs-2.2.1\bochsdbg.exe -q -f config.bxrc
显然，首先要指定调试程序的位置，后面 –q –f表示退出配置选择文件配置，后面的config.bxrc就是刚才运行Bochs所使用的配置文件。下面重点看看如何进行调试。

二：调试
感觉Bochs的调试和DOS提供的Debug很相似——毕竟都是命令行式的调试。如果有一个像TurboDebugger这样的可视化调试工具就好了。（这段文章也是我从网上copy下来的，最后总结为表格的形式，以方便以后查阅）
说明：下面的“[]”表示可有可无的参数在写的时候不要写。
 
执行控制命令
Help 帮助命令，以下的命令都可以通过help命令查到。
c 继续执行，遇到断点将停止
stepi [count] 执行count条指令, 默认为1条
si [count] stepi的缩写
step [count] 执行count条指令, 默认为1条
s [count] step的缩写
Ctrl-C 停止执行，返回命令行
Ctrl-D 执行完所有命令后，退出
quit 退出调试器
q quit缩写
 
设置断点
vbreak seg:off 在指定的虚拟地址（段+偏移）设置断点，在保护模式下也可以使用
vb seg:off
 
lbreak addr 在一个线性地址设置断点
lb addr
 
pbreak [*] addr 在一个物理地址设置断点
pb [*] addr 
break [*] addr
b [*] addr
 
info break 显示所有断点状态
例如：
--------------------------------------
Num Type Disp Enb Address
1 pbreakpoint keep y 0x00007c00
表示在物理地址0x00007c00设置一个断点，该断点目前有效
---------------------------------------
delete n 删除一个断点
del n
d n
 
关于物理地址，线性地址和虚拟地址的区别，我只能凭我的理解简单说说，可能不准确。物理地址在什么时候都存在，但是在采用分页技术和虚拟内存技术后，你很难确定物理地址在那里，所以建议在实模式下采用物理地址和线性地址形式，这时候物理地址和线性地址其实是一致的。最常用的，比方说，计算机启动后的地址是0xfff0:0000，装载BIOS，然后转移到0x07C0:0000，所以总可以设置一个物理断点0x7C00，开始调试你的bootloader。
查看内存
x /nuf addr 查看一个线性地址的内存
xp /nuf addr 查看一个物理地址的内存
n 显示多少个单位的内存
u 内存单位大小，可以是
b 字节
h 字（2个字节）
w 双字（4个字节）
g 4字(8字节)
注意: 它们不太符合Intel字节命名格式，但是遵守GDB约定。
f 打印格式，可以是
x 16进制格式打印
d 10进制格式打印
u 无符号10进制格式打印
o 8进制格式打印
t 2进制格式打印
 
n，f，和u是可选参数。U和f默认为你最后使用的参数, 如果是第一次使用，u默认为w，f默认为x， n默认为1。如果没有指定nuf，那么/也可以不要。setpmem addr datasize val 设置物理地址addr，大小datasize的内存单元的值为val.
 
crc addr1 addr2 对物理地址范围addr1到addr2进行CRC校验？（没用过）info dirty 显示写过的页？（没用过）
 
 
Info
info program 查看程序的执行状态
info registers 列举CPU整型寄存器遗迹它们的内容
info break 显示当前断点信息
where 打印当前call stack
 
寄存器操作
set $reg = val 改变寄存器的内容。可改变的寄存器有:
eax, ecx, edx, ebx, esp, ebp, esi, edi.
不可改变的寄存器有：
eflags, cs, ss, ds, es, fs, gs.
 
例如 set $eax = 0x01234567
set $edx = 25
 
info registers 显示寄存器内容
dump_cpu 查看所有与CPU相关的寄存器状态
set_cpu 设置所有与CPU相关的寄存器状态
dump_cpu和set_cpu格式如下：
"eax:0x%x\n"
"ebx:0x%x\n"
"ecx:0x%x\n"
"edx:0x%x\n"
"ebp:0x%x\n"
"esi:0x%x\n"
"edi:0x%x\n"
"esp:0x%x\n"
"eflags:0x%x\n"
"eip:0x%x\n"
"cs:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"ss:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"ds:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"es:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"fs:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"gs:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"ldtr:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"tr:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n"
"gdtr:base=0x%x, limit=0x%x\n"
"idtr:base=0x%x, limit=0x%x\n"
"dr0:0x%x\n"
"dr1:0x%x\n"
"dr2:0x%x\n"
"dr3:0x%x\n"
"dr4:0x%x\n"
"dr5:0x%x\n"
"dr6:0x%x\n"
"dr7:0x%x\n"
"tr3:0x%x\n"
"tr4:0x%x\n"
"tr5:0x%x\n"
"tr6:0x%x\n"
"tr7:0x%x\n"
"cr0:0x%x\n"
"cr1:0x%x\n"
"cr2:0x%x\n"
"cr3:0x%x\n"
"cr4:0x%x\n"
"inhibit_int:%u\n"
"done\n"


命令
说明
断
点
相
关
vb seg:off  vbreak
在指定的虚拟地址（段+偏移）设置断点，在保护模式下也可以使用
lb addr   lbreak
在一个线性地址设置断点
Pb       pbreak
在一个物理地址设置断点
info break
显示所有断点状态
del n  delete n   d n
删除一个断点
步
进
C
继续执行，遇到断点将停止
step [count]
执行count条指令, 默认为1条
内
存
 
寄
存
器
 
查
看
x /nuf addr
查看一个线性地址的内存
n 显示多少个单位的内存
u 内存单位大小：
可以是，b字节，h字，w 双字，g 4字
f 打印格式：
可以是：16进制，d 10进制，u 无符号10进制，o 8进制，t 2进制
xp /nuf addr
查看一个物理地址的内存
info registers
列举CPU整型寄存器遗迹它们的内容
 
反汇编
      disassemble start end 反汇编的地址范围
      set $disassemble_size = n 告诉调试器，反汇编段的属性（16位或32位，默认32位）。
---http://blog.chinaunix.net/u/15262/showart_411540.html

1. Linux下，如何看每个CPU的使用率：

#top -d 1

（此时会显示以1s的频率刷新系统负载显示，可以看到总的CPU的负载情况，以及占CPU最高的进程id，进程名字等信息）

（切换按下数字1，则可以在显示多个CPU和总CPU中切换）

之后按下数字1. 则显示多个CPU   （top后按1也一样）

Cpu0  :  1.0%us,  3.0%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

 这里对us,sy,ni,id,wa,hi,si,st进行分别说明：

us 列显示了用户模式下所花费 CPU 时间的百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，需要考虑优化用户的程序。

sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足。
ni  列显示了用户进程空间内改变过优先级的进程占用CPU百分比。

id  列显示了cpu处在空闲状态的时间百分比。

wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%，如果wa超过30%，说明IO等待严重，这可能是磁盘大量随机访问造成的，也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。

hi

si

st

2. 在Linux下，如何确认是多核或多CPU:

#cat /proc/cpuinfo

如果有多个类似以下的项目，则为多核或多CPU:

processor       : 0

......

processor       : 1

3. 如何察看某个进程在哪个CPU上运行：

#top -d 1

之后按下f.进入top Current Fields设置页面：

选中：j: P          = Last used cpu (SMP)

则多了一项：P 显示此进程使用哪个CPU。

Sam经过试验发现：同一个进程，在不同时刻，会使用不同CPU Core.这应该是Linux Kernel SMP处理的。

4. 配置Linux Kernel使之支持多Core：

内核配置期间必须启用 CONFIG_SMP 选项，以使内核感知 SMP。

Processor type and features  ---> Symmetric multi-processing support

察看当前Linux Kernel是否支持（或者使用）SMP

#uname -a

5. Kernel 2.6的SMP负载平衡：

在 SMP 系统中创建任务时，这些任务都被放到一个给定的 CPU 运行队列中。通常来说，我们无法知道一个任务何时是短期存在的，何时需要长期运行。因此，最初任务到 CPU 的分配可能并不理想。

为了在 CPU 之间维护任务负载的均衡，任务可以重新进行分发：将任务从负载重的 CPU 上移动到负载轻的 CPU 上。Linux 2.6 版本的调度器使用负载均衡（load balancing） 提供了这种功能。每隔 200ms，处理器都会检查 CPU 的负载是否不均衡；如果不均衡，处理器就会在 CPU 之间进行一次任务均衡操作。

这个过程的一点负面影响是新 CPU 的缓存对于迁移过来的任务来说是冷的（需要将数据读入缓存中）。

记住 CPU 缓存是一个本地（片上）内存，提供了比系统内存更快的访问能力。如果一个任务是在某个 CPU 上执行的，与这个任务有关的数据都会被放到这个 CPU 的本地缓存中，这就称为热的。如果对于某个任务来说，CPU 的本地缓存中没有任何数据，那么这个缓存就称为冷的。

不幸的是，保持 CPU 繁忙会出现 CPU 缓存对于迁移过来的任务为冷的情况。

6. 应用程序如何利用多Core :

开发人员可将可并行的代码写入线程，而这些线程会被SMP操作系统安排并发运行。

另外，Sam设想，对于必须顺序执行的代码。可以将其分为多个节点，每个节点为一个thread.并在节点间放置channel.节点间形如流水线。这样也可以大大增强CPU利用率。

例如：

游戏可以分为3个节点。

1.接受外部信息，声称数据 （1ms）

2.利用数据，物理运算（3ms）

3.将物理运算的结果展示出来。(2ms)

如果线性编程，整个流程需要6ms.

但如果将每个节点作为一个thread。但thread间又同步执行。则整个流程只需要3ms.

gdb断点分类：

以设置断点的命令分类：

breakpoint

可以根据行号、函数、条件生成断点。

watchpoint

监测变量或者表达式的值发生变化时产生断点。

catchpoint

监测信号的产生。例如c++的throw，或者加载库的时候。

gdb中的变量从1开始标号，不同的断点采用变量标号同一管理，可以 用enable、disable等命令管理，同时支持断点范围的操作，比如有些命令接受断点范围作为参数。

例如：disable 5-8

1、break及break变种详解：

相关命令有break，tbreak，rbreak,hbreak，thbreak，后两种是基于硬件的，先不介绍。

>>break 与 tbeak

break，tbreak可以根据行号、函数、条件生成断点。tbreak设置方法与break相同，只不过tbreak只在断点停一次，过后会自动将断点删除，break需要手动控制断点的删除和使能。

break 可带如下参数：

linenum                 本地行号，即list命令可见的行号

filename:linenum  制定个文件的行号

function                函数，可以是自定义函数也可是库函数，如open

filename:function  制定文件中的函数

condtion                条件

 

*address      地址，可是函数，变量的地址，此地址可以通过info add命令得到。

例如：

break 10    

break test.c:10

break main

break test.c:main

break system

break open

如果想在指定的地址设置断点，比如在main函数的地址出设断点。

可用info add main 获得main的地址如0x80484624，然后用break *0x80484624.

条件断点就是在如上述指定断点的同时指定进入断点的条件。

例如：（假如有int 类型变量 index）

break 10 if index == 3

tbreak 12 if index == 5

>>rbreak

rbreak 可以跟一个规则表达式。rbreak + 表达式的用法与grep + 表达式相似。即在所有与表达式匹配的函数入口都设置断点。

 

rbreak list_* 即在所有以 list_ 为开头字符的函数地方都设置断点。

rbreak ^list_ 功能与上同。

>>查看断点信息

info break [break num ]

info break 可列出所有断点信息，info break 后也可设置要查看的break num如：

info break 1 列出断点号是1的断点信息

     Num     Type           Disp Enb  Address    What

     1       breakpoint     keep y    <MULTIPLE>

             stop only if i==1

             breakpoint already hit 1 time

     1.1                         y    0x080486a2 in void foo<int>() at t.cc:8

     1.2                         y    0x080486ca in void foo<double>() at t.cc:8

1. Introduction

   本文介绍了如何在Ubuntu下建立EDKII编译环境，使用QEMU运行EDKII BIOS.

2. 建立EDKII编译环境

       Note: EDKII (12/1/2011 SVN checkout) builds cleanly on 11.10 (with packages in proposed repo installed).

Note: EDKII is known to build correctly on Natty (11.04) but has compilation issues with the more pedantic gcc 4.6.1 ,

         so it fails to build on Oneiric (as of 20 Oct 2011). However, upsteam are aware of this and are working on a fix.

(1) Install required packages
       sudo apt-get install build-essential subversion uuid-dev iasl

       (2) Get the latest source for EDKII

     In a suitable working directory extract the latest EDKII source. Note there is no password for guest account, so hit enter.

      $ mkdir ~/src        $ cd ~/src        $ git clone git://github.com/tianocore/edk2.git

      (4) Compile base tools

    For MS Windows, prebuilt binaries of the base tools are shipped with the source;

    on Ubuntu the base tools required for building EDKII need to be built first.

      $ cd ~/src        $ make -C edk2/BaseTools

(5) Set up build environment
             You need to set EDK_TOOLS_PATH and set up the build environment by running the edksetup.sh script provided in the

      source. This script will copy template and configuration files to edk2/Conf directory.

       $ cd ~/src/edk2         $ export EDK_TOOLS_PATH=$HOME/src/edk2/BaseTools         $ . edksetup.sh BaseTools

      (6) Set up build target
           To set up the build target you need to modify the conf file Conf/target.txt.

    This will enable the firmware package to be built and set up the compiler version used.

     $ vi ~/src/edk2/Conf/target.txt

Find

 ACTIVE_PLATFORM       = Nt32Pkg/Nt32Pkg.dsc 

and replace it with

 ACTIVE_PLATFORM       = MdeModulePkg/MdeModulePkg.dsc 

Find

 TOOL_CHAIN_TAG        = MYTOOLS 

and replace it with your version on GCC here for example GCC 4.4 will be used.

 TOOL_CHAIN_TAG        = GCC44 

Find

 TARGET_ARCH           = IA32 

and replace it with 'X64' for 64bit or 'IA32 X64' to build both architectures.

 TARGET_ARCH           = X64 

3. 编译MdeModulePkg

     This will build the MdeModulePkg and helloworld program that we can use later when we launch the UEFI shell from emulator...    

    Just type build...

  $ cd ~/src/edk2/    $ build

  On a Core i5 with 4GB of RAM the total build time is two minutes. 

4. Build a full system firmware image (OVMF)

   The Open Virtual Machine Firmware (or "OVMF") can be used to enable UEFI within virtual machines. 

   It provides libraries and drivers related to virtual machines. 

   Currently OVMF support QEMU for emulating UEFI on IA32 and X86-64 based systems. 

   You could also build OVMF with source level debugging enabled. 

   Set up build target
   You can build OVMF for IA32 or X64 architechtures. 

In this example we will build OVMF for X64 architecture. 

You will need to modify Conf/target.txt and replace ACTIVE_PLATFORM with the right dsc file. 

$ vi ~/src/edk2/Conf/target.txt

Find 

 ACTIVE_PLATFORM       = MdeModulePkg/MdeModulePkg.dsc  

replace with 

 ACTIVE_PLATFORM       = OvmfPkg/OvmfPkgX64.dsc  

This will set the Target Arch to X64, PEI code to X64 and DXE/UEFI code to X64. 

Build the OvmfPkg
    $ cd ~/src/edk2      $ build

On an i5 with 4GB RAM the total build time is less than two minutes. The files built will be located 

under ~/src/Build/ 

Building the OvmfPkg with Secure Boot support
    If you wish to build OVMF with Secure Boot, you must follow the openssl installation instructions 

found in:- 

~/src/edk2/CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt

and build like this instead:- 

$ cd ~/src/edk2     $ build –D SECURE_BOOT_ENABLE

If you see an error that "the required fv image size exceeds the set fv image size" consult this mailing list post. 

But note that the rest of this guide currently assumes you build WITHOUT Secure Boot. 

5. Running UEFI in QEMU

       $ sudo apt-get install qemu

Initial setup

create a directory where you will set up firmware, a directory to use as hard disk image for QEMU.

    $ mkdir ~/ovmf-qemu      $ cd ~/ovmf-qemu      $ mkdir hda-contents

Copy the firmware to your working directory.

    $ cd ~/ovmf-qemu      $ cp ~/src/edk2/Build/OvmfX64/DEBUG_GCC45/FV/OVMF.fd ./bios.bin      $ cp ~/src/edk2/Build/OvmfX64/DEBUG_GCC45/FV/OvmfVideo.rom ./vgabios-cirrus.bin

Run UEFI image in QEMU
          This will launch UEFI firmware image on QEMU and drop to UEFI shell.

   You can type exit and get to the UEFI menus or work with the shell.

   Note: to release mouse grab from QEMU hit CTRL+ALT

     $ qemu-system-x86_64 -L . -hda fat:hda-contents

6. Running HelloWorld.efi

    
As part of the MdeModule build, you also built a HelloWorld.efi. Exit any QEMU sessions you are running and copy the hello world program to your QEMU hard disk. 
$ cp ~/src/edk2/Build/MdeModule/DEBUG_GCC45/X64/HelloWorld.efi ~/ovmf-qemu/hda-contents/.
Launch UEFI firmware in QEMU, and run the hello world program. 

7. 在QEMU上利用OVMF启动Ubuntu 12.04

You can boot the Ubuntu live CD image using OVMF as your firmware. Please note that splash screen does not work, and you might not be able to get a network connection, but the OS will boot and will be fully functional. I have precise-desktop-amd64.iso downloaded to ~/Downloads/iso/12.04/, I change directory to where I copied the firmware I built and run QEMU with the following options.

$ cd ~/ovmf-qemu  $ qemu-system-x86_64 -L . -m 1024 -cdrom ~/Downloads/iso/12.04/precise-desktop-amd64.iso -vga cirrus -enable-kvm

TCG（Tiny Code Generator）最早被用于C编译器的后端。在TCG相关的代码中，target指的是我们通常说的host，这一点需要注意，并不是我们理解的被仿真的平台。

2. TCG动态翻译技术的几个概念

（1）与dyngen一样，TCG的“function”与qemu的TBs（Translated Block）相对应，即以分支跳转指令结束的代码段。

（2）TCG中有三种变量：temporary， local temporary， global。这三种变量有着不同的生命周期，temporary变量的声明周期是TBs，local temporary变量的声明周期是functions，global变量的声明周期是所有的functions，类似C语言的全局变量。temporary和local temporary变量通常在function内定义，global变量通常在function外定义。全局变量通常被映射到某个内存地址或某个固定的寄存器。

3. TCG operations

就像dyngen动态翻译技术中的micro-operations一样，TCG也采用中间表示的形式(TCG instructions)，TCG至中间表示支持的三种变量有两种数据类型：32 bit整型和64 bit整型。另外，指针类型被实现为整型的别名。

TCG指令有固定的形式：

TCG 操作码 输出变量域，输入变量域，常量域

比较特殊的是call指令，其后只跟一个变量，同时作为输出和输入变量域。

举个例子：

add_i32 t0, t1, t2 (t0 <- t1 + t2)

操作码 输出变量域 输入变量域 常量域（输入）

4. TCG是qemu的核心，主要实现了以下翻译流程：

在下一篇文章中，将会从qemu源码的角度详细分析x86-->x86平台的TCG动态翻译技术的执行过程。

1. 明确guest和host

    对于qemu而言，被仿真的平台成为guest或者说target；很明显，运行qemu的平台就称为host。

2. 了解qemu动态翻译技术的发展

    qemu运用动态翻译的技术将guest binary instructions动态翻译成host binary instructions，之后由host运行翻译后的指令。在qemu-0.9之前的版本都采用dyngen的动态翻译技术，而从qemu-0.10开始的版本开始采用TCG（Tiny  Code Generator）的翻译技术。

    采用dyngen  动态翻译技术的资料主要有以下两篇文章，是了解动态翻译技术入门的好文章（在后续的分析中，会简单介绍dyngen技术）：

•   QEMU, a Fast and Portable Dynamic Translator

•  Porting QEMU to Plan 9: QEMU Internals and Port Strategy

    介绍TCG技术的文章则相对较少，主要是阅读qemu源码和qemu官网上的相关资料。

3. dyngen简单介绍

     图1简单说明了qemu采用dyngen动态翻译技术将目标平台指令翻译成主机平台指令的简单过程。

假设target为PowerPC，host为x86，说明整个翻译过程：

为了更容易理解动态翻译技术，我们暂时忽略掉qemu的其他模块，如用户交互模块，硬件模拟等模块，而是从数据结构的设计，数据结构之间的操作及其应用等方面来进行详细地分析，重点关注动态翻译器和微操作库(micro-ops library)的原理，至于细节的东西可以放在以后去深入分析。

qemu利用了一种可移植的动态代码翻译器以快速地完成客户代码的仿真。qemu本身并不能识别它主机体系结构的指令集，作为替代，每一个客户机指定一个c语言实现的微操作库以及一个客户机代码反汇编器和翻译器，用来将客户代码转换成微操作表，这些微操作可以被认为是一种虚拟机，尽管仅仅是对客户系统模拟的一种优化而已。另外，这些操作本身包括寄存器转化，显示的条件代码更新代码，按位操作，整型和浮点型数学函数，内存加载和存储操作等。

2.1 翻译

2.1.1 基本块的翻译

图1描述了一小段带条件跳转x86代码以及其对应的微操作指令表示，每一条op_开头的微操作指令都将被拷贝到翻译缓冲区中，微操作指令中看起来像参数的常量被称为折叠常量(const folding)，在2.3.4接将会进行详细的解释，现在只要把它看成是qemu中定义的微操作指令的参数就可以了。微操作指令的参数中，tb是比较特殊的，它指向与当前翻译缓冲区相关的元数据。另外，JNZ指令对应的微操作指令看起来比较怪异，控制流处理相关的细节将会在2.2.3节和2.2.4节详细介绍。

2.1.2 同步的错误安全舱口

严格的按照“基本块”（basic block）的方式译码将会使得翻译缓冲区中包含一条或多条客户机指令，同时几乎每一条指令都可能产生同步的fault(比方说MMU fault)。为了便于理解，在翻译的时候我们重点考虑比较直接的客户机控制流（比方说，分支跳转：条件跳转和非条件跳转），毕竟，同步的错误(fault)很少出现。对于同步错误(fault)需要一种恢复机制，用来处理翻译缓冲区中的fault。qemu使用longjmp()从翻译缓冲区中跳到仿真器核心代码中。这里描述的意思是：当在执行翻译缓冲区的代码时，遇到了fault，就需要将执行路径切换到qemu的代码中，另外，当qemu处理完fault后，会重新创建一个翻译缓冲区。

2.1 翻译缓冲区的高超技巧

qemu采用了一些不同寻常的技巧来提高性能：

• 冗长的、额外开销大的主机操作（如仿真客户的MMU操作）并不会被直接放进翻译缓冲区，而是以可以从微操作中调用的帮助函数的形式存在
  • 一方面减少了对翻译缓冲区的占用，另一方面简化了翻译的过程（qemu中事先保存某些固定指令的翻译结果，当动态翻译器碰到这些指令时，直接跳过去执行就行了）
• 翻译后的微操作指令序列的优化
• 启发式的译码和翻译

2.2.1 通过函数调用来达到节省翻译缓冲区的技术

目前操作系统中的MMU操作指令自身非常复杂。对于MMU操作会产生大量的访存操作，通常的解决方法是增加一个cache，但这进一步增加代码的复杂度。如果将每一次访存操作的这些复杂代码都放入翻译缓冲区中，其代价将会非常的昂贵。除了MMU操作指令，一些特殊的客户机指令也是非常复杂的，如CPUID指令，即使在简化的qemu的实现中，一条x86的CPUID指令都需要75行C代码来实现。与ARPL指令相比，CPUID对于不同的寄存器内容将会表现是完全不同的行为，因此，必须需要一大串冗长的微操作指令来实现CPUID的功能。

为了优化这种代价昂贵，需要冗长的微操作指令来实现的客户机指令，qemu采用能够实现类似函数调用功能的微操作指令的机制来实现，比如ldl_kernel，实现了内核模式的大量数据的读功能；helper_cpuid，这个微操作包含了CPUID指令的实现。

2.2.2 惰性赋值

每一条指令都会隐含性修改指令指针(EIP)，并且每一条指令都会修改处理器条件码（比如零标志位，溢出标志位、进位标志位等），但实际的情况是，只要指令按照正确的顺序执行，其实客户代码很少去关心这些状态的变化。对于这些条件码除了条件跳转状态位外，我们很少去关注其他的状态位。图1中一段小小的客户代码都会引起指令指针的修改和条件码修改的大量操作：

• ADDL操作会修改条件码的零和进位/借位标志位
• SUBL操作会修改条件码的零和进位/借位标志位
• ADDL和SUBL都会修改EIP，使其指向下一条指令

由于qemu是按照“基本代码块”为单位进行翻译的，所以只有在整个“基本代码块”翻译完成或显示的读取EIP的时候才会对EIP进行更新，这就避免了EIP的频繁更新的问题。在实际情况下，ADDL和SUBL都不会去读指令指针EIP，因此，可以优化掉翻译后的微操作指令中对EIP更新的微操作，具体描述如图2所示。图2中仅仅是在每个“基本代码块”的最后通过op_jmp_im微操作来进行EIP的更新，即每个“基本代码块”只做一次更新操作。

Target指令 ----> TCG ----> Host指令

以下的讲述以X86平台为例（Host和Target都是X86）。

我在上篇文章中讲到，动态翻译的基本思想就是把每一条Target指令切分成为若干条微指令，每条微指令由一段简单的C代码来实现，运行时通过一个动态代码生成器把这些微指令组合成一个函数，最后执行这个函数，就相当于执行了一条Target指令。

这种思想的基础是因为CPU指令都是很规则的，每条指令的长度、操作码、操作数都有固定格式，根据前面就可推导出后面，所以只需通过反汇编引擎分析出指令的操作码、输入参数、输出参数等，剩下的工作就是编码为目标指令了。

那么现在的CPU指令这么多，怎么知道要分为哪些微指令呢？其实CPU指令看似名目繁多，异常复杂，实际上多数指令不外乎以下几大类：

数据传送、算术运算、逻辑运算、程序控制；

例如，数据传送包括：传送指令（如MOV）、堆栈操作（PUSH、POP）等

程序控制包括：函数调用（CALL）、转移指令（JMP）等；

基于此，TCG就把微指令按以上几大类定义（见tcg/i386/tcg-target.c），例如：其中一个最简单的函数 tcg_out_movi 如下：

// tcg/tcg.c
static inline void tcg_out8(TCGContext *s, uint8_t v)
{
*s->code_ptr++ = v;
}

static inline void tcg_out32(TCGContext *s, uint32_t v)
{
*(uint32_t *)s->code_ptr = v;
s->code_ptr += 4;
}

// tcg/i386/tcg-target.c
static inline void tcg_out_movi(TCGContext *s, TCGType type,
int ret, int32_t arg)
{
if (arg == 0) {
/* xor r0,r0 */
tcg_out_modrm(s, 0x01 | (ARITH_XOR << 3), ret, ret);
} else {
tcg_out8(s, 0xb8 + ret); // 输出操作码，ret是寄存器索引
tcg_out32(s, arg); // 输出操作数
}
}

0xb8 - 0xbf 正是x86指令中的 mov R, Iv 系列操作的16进制码，所以，tcg_out_movi 的功能就是输出 mov 操作的指令码到缓冲区中。可以看出，TCG在生成目标指令的过程中是采用硬编码的，因此，要让TCG运行在不同的Host平台上，就必须为不同的平台编写微操作函数。

接下来，我还是以一条Target指令 jmp f000:e05b 来讲述它是如何被翻译成Host指令的。其中几个关键变量的定义如下：

gen_opc_buf： 操作码缓冲区
gen_opparam_buf：参数缓冲区
gen_code_buf： 存放翻译后指令的缓冲区
gen_opc_ptr、gen_opparam_ptr、gen_code_ptr三个指针变量分别指向上述缓冲区。

jmp f000:e05b 的编码是：EA 5B E0 00 F0，

首先是disas_insn()函数翻译指令，当碰到第1个字节EA，分析可知这是一条16位无条件跳转指令，因此依次从后续字节中得到offset和selector，然后分为如下微指令操作：

gen_op_movl_T0_im(selector);
gen_op_movl_T1_imu(offset);
gen_op_movl_seg_T0_vm(R_CS);
gen_op_movl_T0_T1();
gen_op_jmp_T0();

这几个微指令函数的定义如下（功能可看注释）：

static inline void gen_op_movl_T0_im(int32_t val)
{
tcg_gen_movi_tl(cpu_T[0], val); // 相当于 cpu_T[0] = val
}

static inline void gen_op_movl_T1_imu(uint32_t val)
{
tcg_gen_movi_tl(cpu_T[1], val); // 相当于 cpu_T[1] = val
}

static inline void gen_op_movl_seg_T0_vm(int seg_reg)
{
tcg_gen_andi_tl(cpu_T[0], cpu_T[0], 0xffff); // cpu_T[0] = cpu_T[0]&0xffff
tcg_gen_st32_tl(cpu_T[0], cpu_env, 
offsetof(CPUX86State,segs[seg_reg].selector)); // the value of cpu_T[0] store to the 'offset' of cpu_env
tcg_gen_shli_tl(cpu_T[0], cpu_T[0], 4); // cpu_T[0] = cpu_T[0]<<4
tcg_gen_st_tl(cpu_T[0], cpu_env, 
offsetof(CPUX86State,segs[seg_reg].base)); // the value of cpu_T[0] store to the 'offset' of cpu_env
}

static inline void gen_op_movl_T0_T1(void)
{
tcg_gen_mov_tl(cpu_T[0], cpu_T[1]); // cpu_T[0] = cpu_T[1]
}

static inline void gen_op_jmp_T0(void)
{
tcg_gen_st_tl(cpu_T[0], cpu_env, offsetof(CPUState, eip)); // // the value of cpu_T[0] store to the 'offset' of cpu_env
}

其中，cpu_T[0]、cpu_T[1]和前面讲过的T0、T1功能一样，都是用来临时存储的变量。在32位目标机上，tcg_gen_movi_tl 就是 tcg_gen_op2i_i32 函数，它的定义如下：

static inline void tcg_gen_op2i_i32(int opc, TCGv_i32 arg1, TCGArg arg2)
{
*gen_opc_ptr++ = opc;
*gen_opparam_ptr++ = GET_TCGV_I32(arg1);
*gen_opparam_ptr++ = arg2;
}

static inline void tcg_gen_movi_i32(TCGv_i32 ret, int32_t arg)
{
tcg_gen_op2i_i32(INDEX_op_movi_i32, ret, arg);
}

gen_opparam_buf 是用来存放操作数的缓冲区，它的存放顺序是：第1个4字节代表s->temps（用来存放目标值的数组，即输出参数）的索引，第2个4字节及之后字节代表输入参数，对它的具体解析过程可见 tcg_reg_alloc_movi 函数，示例代码如下：

TCGTemp *ots;
tcg_target_ulong val;

ots = &s->temps[args[0]];
val = args[1];

ots->val_type = TEMP_VAL_CONST;
ots->val = val; // 把输入值暂时存放在ots结构中

接下来，根据 gen_opc_buf 保存的操作码列表，gen_opparam_buf 保存的参数列表，以及TCGContext结构，经过 tcg_gen_code_common 函数调用，jmp f000:e05b 生成的最终指令如下：

099D0040 B8 00 F0 00 00 mov eax,0F000h 
099D0045 81 E0 FF FF 00 00 and eax,0FFFFh 
099D004B 89 45 50 mov dword ptr [ebp+50h],eax 
099D004E C1 E0 04 shl eax,4 
099D0051 89 45 54 mov dword ptr [ebp+54h],eax 
099D0054 B8 5B E0 00 00 mov eax,0E05Bh 
099D0059 89 45 20 mov dword ptr [ebp+20h],eax 
099D005C 31 C0 xor eax,eax 
099D005E E9 25 5D CA 06 jmp _code_gen_prologue+8 (10675D88h) /* 返回 */

从上面可以看出，生成的Host代码很简洁，对于Target机的JMP，Host没有去执行真正的跳转指令，而只是简单的将目标地址放到EIP中而已。

QEMU维护着一个称为 CPUState 的数据结构，这个结构包括了Target机CPU的所有寄存器，像EAX，EBP，ESP，CS，EIP，EFLAGS等。

它总是代表着Target机的当前状态，我用env变量来表示 CPUState 结构，

QEMU每次解析Target指令时，总是以 env.cs+env.eip 为开始地址的。 

像上面说的jmp f000:e05b指令，它分解为如下微操作： 

gen_op_movl_T0_im(selector); 
gen_op_movl_T1_imu(offset); 
gen_op_movl_seg_T0_vm(R_CS); 
gen_op_movl_T0_T1(); 
gen_op_jmp_T0(); 

这几条微操作的意义概括起来很简单，就是把selector放到env.cs，把offset放到env.eip。在调试中，把QEMU执行Target指令的过程和Bochs比较是一件很有趣的事情，当然，这只是设计理念的不同，而并没有技术上的优劣之分。

    qemu是一种快速的多体系结构仿真器，通过动态翻译的技术达到了优异的仿真速度。目前，qemu支持两种操作模式：

• 全系统仿真模式。在这种模式下，qemu完整的仿真目标平台，此时，qemu就相当于一台完整的pc机，例如包括一个或多个处理器以及各种外围设备。这种模式可以用来运行不同的操作系统或调试操作系统的代码。
• 用户态仿真模式。在这种模式下，qemu能够运行不同于主机平台的其他平台的程序（比如，在x86平台上运行为arm平台编译的程序），其中典型的代表wine windows API emulator。另外，在这种模式下能够进行方便的交叉编译和调试。

    对于全系统仿真模式，qemu目前可以支持的硬件列表如下：

• x86 or x86_64 体系结构处理器
• ISA PC （没有PCI总线的PC）
• PowerPC 处理器
• 32/64bit的SPARC 处理器
• 32/64bit的MIPS处理器
• ARM体系结构的处理器
• PXA 270、PXA 255
• OMAP 310、OMAP 2420、OMAP 310

    对于用户态仿真模式，qemu支持的硬件列表如下：x86 (32 and 64 bit), PowerPC (32 and 64 bit), ARM, MIPS (32 bit only), Sparc (32 and 64 bit), Alpha, ColdFire(m68k), CRISv32 and MicroBlaze CPUs are supported.

1.1 qemu 的本质

     众所周知，Bochs 是一款可移植的IA-32仿真器，它利用模拟的技术来仿真目标系统，具体来说，将是将目标系统的指令分解，然后模拟分解后的指令以达到同样的效果。这种方法将每一条目标指令分解成多条主机系统的指令，很明显会大大降低仿真的速度。

    qemu则是采用动态翻译的技术，先将目标代码翻译成一系列等价的被称为“微操作”（micro-operations）的指令，然后再对这些指令进行拷贝，修改，连接，最后产生一块本地代码。这些微操作排列复杂，从简单的寄存器转换模拟到整数/浮点数学函数模拟再到load/store操作模拟，其中load/store操作的模拟需要目标操作系统分页机制的支持。

    qemu对客户代码的翻译是按块进行的，并且翻译后的代码被缓存起来以便将来重用。在没有中断的情况下，翻译后的代码仅仅是被链接到一个全局的链表上，目的是保证整个控制流保持在目标代码中，当异步的中断产生时，中断处理函数就会遍历串连翻译后代码的全局链表来在主机上执行翻译后的代码，这就保证了控制流从目标代码跳转到qemu代码。简单概括下：指定某个中断来控制翻译代码的执行，即每当产生这个中断时才会去执行翻译后的代码，没有中断时仅仅只是个翻译过程而已。这样做的好处就是，代码是是按块翻译，按块执行的，不像Bochs翻译一条指令，马上就执行一条指令。

1.2 qemu能够模拟的硬件

    Bochs和qemu从非常低的层次对硬件进行模拟，对于像总线和外围设备如显卡，网卡，磁盘控制器等都有相对应的软件的表示，但是二者仅对有限的硬件集合进行精确的模拟，比如对中断控制器，总线驱动，磁盘驱动，键盘，鼠标，显卡以及网卡的模拟。随着时间的推移，可模拟的硬件集合将会扩展到客户操作系统能够支持的尽可能多的设备。Qemu和Bochs都利用运行在模拟机中的BIOSes来初始化硬件的某些部分，这种设计思想使得对设备的仿真忠于原始的硬件。

    除了模拟之外，设备驱动利用主机的功能来提供模拟和用户要求的功能，下面来看几个例子：

• 帧缓冲区通过用户可选择的接口被暴露出来，对于qemu来说，帧缓冲有SDL window，VNC Server和无图形界面的输出三个可供选择的选项
• qemu中的网络可以是被禁止的，可以是被桥接到主机的，可以使用虚拟以太网协议创建的Unix套接字，还可以是被在qemu中被完全模拟的

1.3 可移植性

    qemu采用了模块化的设计思想，仿真器中与目标平台相关的部分被分离到它们自己的文件和目录中。对于核心部分，驱动部分和动态翻译器来说，所有目标平台都声明相同的接口，在整个qemu的111，000行代码中，目标平台相关的组件代码大约占了1/3，特别地，x86目标平台的大约不超过8000行。与Bochs不同的是，qemu对目标平台的描述非常的紧凑，因此，可以模拟大量的目标平台。

    qemu要求公开有关编译执行的信息以便动态翻译器使用，幸运地是，这些信息中的绝大部分对于调试器，动态连接器和单独编译来说都是非常必要的。另外，qemu完全由C语言编写，在主机和目标平台环境之间创建了一个隔离层。值得一提的是动态翻译器使用了带GNU扩展的C编写，这种结构化的可移植性，再加上GCC对大量系统的支持，使得qemu在主机系统之间的可移植性大大增加。

    本文仅仅简单介绍下了qemu的相关知识，下一篇文章将会深入分析qemu的实现原理。

一、函数的调用语法
函数调用，很像变量的使用，也是以“$”来标识的，其语法如下：
$(<function> <arguments> ) 
或是
${<function> <arguments>}

这里，<function>就是函数名，make支持的函数不多。<arguments>是函数的参数，参数 
间以逗号“,”分隔，而函数名和参数之间以“空格”分隔。函数调用以“$”开头，以圆 
括号或花括号把函数名和参数括起。感觉很像一个变量，是不是？函数中的参数可以使 
用变量，为了风格的统一，函数和变量的括号最好一样，如使用“$(substa,b,$(x))”这 
样的形式，而不是“$(substa,b,${x})”的形式。因为统一会更清楚，也会减少一些不必 
要的麻烦。
还是来看一个示例：
comma:= , 
empty:= 
space:= $(empty) $(empty) 
foo:= a b c 
bar:= $(subst $(space),$(comma),$(foo))
在这个示例中，$(comma)的值是一个逗号。$(space)使用了$(empty)定义了一个空格， 
$(foo)的值是“a b c”，$(bar)的定义用，调用了函数“subst”，这是一个替换函数，这 
个函数有三个参数，第一个参数是被替换字串，第二个参数是替换字串，第三个参数 
是替换操作作用的字串。这个函数也就是把$(foo)中的空格替换成逗号，所以$(bar)的值 
是“a,b,c”。

二、字符串处理函数

$(subst <from>,<to>,<text> )

名称：字符串替换函数——subst。 
功能：把字串<text>中的<from>字符串替换成<to>。 
返回：函数返回被替换过后的字符串。

示例：
$(subst ee,EE,feet on the street)，
把“feetonthestreet”中的“ee”替换成“EE”，返回结果是“fEEtonthestrEEt”。

$(patsubst <pattern>,<replacement>,<text> ) 

名称：模式字符串替换函数——patsubst。 
功能：查找<text>中的单词（单词以“空格”、“Tab”或“回车”“换行”分隔）是否 
符合模式<pattern>，如果匹配的话，则以<replacement>替换。这里，<pattern>可以包括 
通配符“%”，表示任意长度的字串。如果<replacement>中也包含“%”，那么， 
<replacement>中的这个“%”将是<pattern>中的那个“%”所代表的字串。（可以用“\” 
来转义，以“\%”来表示真实含义的“%”字符） 
返回：函数返回被替换过后的字符串。

示例：
$(patsubst %.c,%.o,x.c.c bar.c)
把字串“x.c.cbar.c”符合模式[%.c]的单词替换成[%.o]，返回结果是“x.c.obar.o”
备注：
这和我们前面“变量章节”说过的相关知识有点相似。如：

“$(var:<pattern>=<replacement> )” 
相当于 
“$(patsubst <pattern>,<replacement>,$(var))”，

而“$(var:<suffix>=<replacement>)” 
则相当于 
“$(patsubst %<suffix>,%<replacement>,$(var))”。

例如有：objects=foo.obar.obaz.o， 
那么，“$(objects:.o=.c)”和“$(patsubst%.o,%.c,$(objects))”是一样的。

$(strip <string> )

名称：去空格函数——strip。 
功能：去掉<string>字串中开头和结尾的空字符。 
返回：返回被去掉空格的字符串值。 
示例：
$(strip a b c )
把字串“abc”去到开头和结尾的空格，结果是“abc”。
$(findstring <find>,<in> )

名称：查找字符串函数——findstring。 

功能：在字串<in>中查找<find>字串。 
返回：如果找到，那么返回<find>，否则返回空字符串。 
示例：
$(findstring a,a b c) 
$(findstring a,b c)
第一个函数返回“a”字符串，第二个返回“”字符串（空字符串）
$(filter <pattern...>,<text> )
名称：过滤函数——filter。 
功能：以<pattern>模式过滤<text>字符串中的单词，保留符合模式<pattern>的单词。可 
以有多个模式。 
返回：返回符合模式<pattern>的字串。 
示例：

sources := foo.c bar.c baz.s ugh.h 
foo: $(sources) 
cc $(filter %.c %.s,$(sources)) -o foo

$(filter %.c %.s,$(sources))返回的值是“foo.c bar.c baz.s”。

$(filter-out <pattern...>,<text> )

名称：反过滤函数——filter-out。 
功能：以<pattern>模式过滤<text>字符串中的单词，去除符合模式<pattern>的单词。可 
以有多个模式。 
返回：返回不符合模式<pattern>的字串。 
示例：

objects=main1.o foo.o main2.o bar.o 
mains=main1.o main2.o

$(filter-out $(mains),$(objects)) 返回值是“foo.o bar.o”。

$(sort <list> )

名称：排序函数——sort。 
功能：给字符串<list>中的单词排序（升序）。 
返回：返回排序后的字符串。 
示例：$(sortfoobarlose)返回“barfoolose”。 
备注：sort函数会去掉<list>中相同的单词。 

$(word <n>,<text> )

名称：取单词函数——word。 
功能：取字符串<text>中第<n>个单词。（从一开始） 
返回：返回字符串<text>中第<n>个单词。如果<n>比<text>中的单词数要大，那么返回 
空字符串。 
示例：$(word2,foobarbaz)返回值是“bar”。

$(wordlist <s>,<e>,<text> )

名称：取单词串函数——wordlist。 
功能：从字符串<text>中取从<s>开始到<e>的单词串。<s>和<e>是一个数字。 
返回：返回字符串<text>中从<s>到<e>的单词字串。如果<s>比<text>中的单词数要大， 
那么返回空字符串。如果<e>大于<text>的单词数，那么返回从<s>开始，到<text>结束 
的单词串。 
示例：$(wordlist2,3,foobarbaz)返回值是“barbaz”。

$(words <text> )

名称：单词个数统计函数——words。 
功能：统计<text>中字符串中的单词个数。 
返回：返回<text>中的单词数。 
示例：$(words,foobarbaz)返回值是“3”。 
备注：如果我们要取<text>中最后的一个单词，我们可以这样：$(word $(words 
<text> ),<text> )。

$(firstword <text> )

名称：首单词函数——firstword。 
功能：取字符串<text>中的第一个单词。 
返回：返回字符串<text>的第一个单词。 
示例：$(firstwordfoobar)返回值是“foo”。 
备注：这个函数可以用word函数来实现：$(word1,<text>)。

以上，是所有的字符串操作函数，如果搭配混合使用，可以完成比较复杂的功能。这里， 
举一个现实中应用的例子。我们知道，make使用“VPATH”变量来指定“依赖文件”的 
搜索路径。于是，我们可以利用这个搜索路径来指定编译器对头文件的搜索路径参数 
CFLAGS，如：

override CFLAGS += $(patsubst %,-I%,$(subst :, ,$(VPATH)))

如果我们的“$(VPATH)”值是“src:../headers”，那么“$(patsubst %,-I%,$(subst :, , 
$(VPATH)))”将返回“-Isrc -I../headers”，这正是 cc 或 gcc 搜索头文件路径的参数。 

三、文件名操作函数

下面我们要介绍的函数主要是处理文件名的。每个函数的参数字符串都会被当做一个或 
是一系列的文件名来对待。

$(dir <names...> )

名称：取目录函数——dir。 
功能：从文件名序列<names>中取出目录部分。目录部分是指最后一个反斜杠（“/”） 
之前的部分。如果没有反斜杠，那么返回“./”。 
返回：返回文件名序列<names>的目录部分。 
示例：$(dirsrc/foo.chacks)返回值是“src/./”。

$(notdir <names...> )

名称：取文件函数——notdir。 
功能：从文件名序列<names>中取出非目录部分。非目录部分是指最后一个反斜杠（“/ 
”）之后的部分。 
返回：返回文件名序列<names>的非目录部分。 
示例：$(notdirsrc/foo.chacks)返回值是“foo.chacks”。

$(suffix <names...> )

名称：取后缀函数——suffix。 
功能：从文件名序列<names>中取出各个文件名的后缀。 
返回：返回文件名序列<names>的后缀序列，如果文件没有后缀，则返回空字串。 
示例：$(suffixsrc/foo.csrc-1.0/bar.chacks)返回值是“.c.c”。

$(basename <names...> )

名称：取前缀函数——basename。 
功能：从文件名序列<names>中取出各个文件名的前缀部分。 
返回：返回文件名序列<names>的前缀序列，如果文件没有前缀，则返回空字串。 
示例：$(basenamesrc/foo.csrc-1.0/bar.chacks)返回值是“src/foosrc-1.0/barhacks”。

$(addsuffix <suffix>,<names...> )

名称：加后缀函数——addsuffix。 
功能：把后缀<suffix>加到<names>中的每个单词后面。 
返回：返回加过后缀的文件名序列。 
示例：$(addsuffix.c,foobar)返回值是“foo.cbar.c”。 

$(addprefix <prefix>,<names...> )

名称：加前缀函数——addprefix。 
功能：把前缀<prefix>加到<names>中的每个单词后面。 
返回：返回加过前缀的文件名序列。 
示例：$(addprefixsrc/,foobar)返回值是“src/foosrc/bar”。

$(join <list1>,<list2> )

名称：连接函数——join。 
功能：把<list2>中的单词对应地加到<list1>的单词后面。如果<list1>的单词个数要比 
<list2>的多，那么，<list1>中的多出来的单词将保持原样。如果<list2>的单词个数要比 
<list1>多，那么，<list2>多出来的单词将被复制到<list2>中。 
返回：返回连接过后的字符串。 
示例：$(joinaaabbb,111222333)返回值是“aaa111bbb222333”。

 
四、foreach函数

foreach 函数和别的函数非常的不一样。因为这个函数是用来做循环用的，Makefile 中的 
foreach 函数几乎是仿照于 Unix 标准 Shell（/bin/sh）中的 for 语句，或是 C-Shell 
（/bin/csh）中的foreach语句而构建的。它的语法是：

$(foreach <var>,<list>,<text> )

这个函数的意思是，把参数<list>中的单词逐一取出放到参数<var>所指定的变量中， 
然后再执行<text>所包含的表达式。每一次<text>会返回一个字符串，循环过程中， 
<text>的所返回的每个字符串会以空格分隔，最后当整个循环结束时，<text>所返回的 
每个字符串所组成的整个字符串（以空格分隔）将会是foreach函数的返回值。

所以，<var>最好是一个变量名，<list>可以是一个表达式，而<text>中一般会使用 
<var>这个参数来依次枚举<list>中的单词。举个例子： 

names := a b c d

files := $(foreach n,$(names),$(n).o)

上面的例子中，$(name)中的单词会被挨个取出，并存到变量“n”中，“$(n).o”每次根 
据“$(n)”计算出一个值，这些值以空格分隔，最后作为foreach函数的返回，所以， 
$(files)的值是“a.o b.o c.o d.o”。

注意，foreach中的<var>参数是一个临时的局部变量，foreach函数执行完后，参数 
<var>的变量将不在作用，其作用域只在 foreach 函数当中。

五、if函数

if 函数很像 GNU 的 make 所支持的条件语句——ifeq（参见前面所述的章节），if 函数 
的语法是：

$(if <condition>,<then-part> )

或是

$(if <condition>,<then-part>,<else-part> )

可见，if函数可以包含“else”部分，或是不含。即if函数的参数可以是两个，也可以是 
三个。<condition>参数是if的表达式，如果其返回的为非空字符串，那么这个表达式就 

相当于返回真，于是，<then-part>会被计算，否则<else-part>会被计算。

 
而if函数的返回值是，如果<condition>为真（非空字符串），那个<then-part>会是整 
个函数的返回值，如果<condition>为假（空字符串），那么<else-part>会是整个函数的 
返回值，此时如果<else-part>没有被定义，那么，整个函数返回空字串。 
所以，<then-part>和<else-part>只会有一个被计算。

六、call函数

call 函数是唯一一个可以用来创建新的参数化的函数。你可以写一个非常复杂的表达式， 
这个表达式中，你可以定义许多参数，然后你可以用call函数来向这个表达式传递参 
数。其语法是：

$(call <expression>,<parm1>,<parm2>,<parm3>...)

当make执行这个函数时，<expression>参数中的变量，如$(1)，$(2)，$(3)等，会被参 
数<parm1>，<parm2>，<parm3>依次取代。而<expression>的返回值就是call函数的返 
回值。例如：

reverse = $(1) $(2)

foo = $(call reverse,a,b)

那么，foo的值就是“ab”。当然，参数的次序是可以自定义的，不一定是顺序的，如： 

reverse = $(2) $(1)

foo = $(call reverse,a,b)

此时的foo的值就是“ba”。 
七、origin函数 
origin 函数不像其它的函数，他并不操作变量的值，他只是告诉你你的这个变量是哪里 
来的？其语法是： 
$(origin <variable> )

注意，<variable>是变量的名字，不应该是引用。所以你最好不要在<variable>中使用“ 
$”字符。Origin 函数会以其返回值来告诉你这个变量的“出生情况”，下面，是 origin 
函数的返回值:

“undefined” 
如果<variable>从来没有定义过，origin函数返回这个值“undefined”。 
“default”

如果<variable>是一个默认的定义，比如“CC”这个变量，这种变量我们将在后面讲述。 

“environment” 
如果<variable>是一个环境变量，并且当Makefile被执行时，“-e”参数没有被打开。

“file”

如果<variable>这个变量被定义在Makefile中。 
“command line”

如果<variable>这个变量是被命令行定义的。

 
“override”

如果<variable>是被override指示符重新定义的。

 
“automatic” 
如果<variable>是一个命令运行中的自动化变量。关于自动化变量将在后面讲述。 
这些信息对于我们编写Makefile是非常有用的，例如，假设我们有一个Makefile其包 
了一个定义文件Make.def，在Make.def中定义了一个变量“bletch”，而我们的环境中 
也有一个环境变量“bletch”，此时，我们想判断一下，如果变量来源于环境，那么我 
们就把之重定义了，如果来源于Make.def或是命令行等非环境的，那么我们就不重新 
定义它。于是，在我们的Makefile中，我们可以这样写： 
ifdef bletch 

ifeq "$(origin bletch)" "environment" 
bletch = barf, gag, etc. 
endif 
endif 
当然，你也许会说，使用override关键字不就可以重新定义环境中的变量了吗？为什 
么需要使用这样的步骤？是的，我们用override是可以达到这样的效果，可是override 
过于粗暴，它同时会把从命令行定义的变量也覆盖了，而我们只想重新定义环境传来 
的，而不想重新定义命令行传来的。

八、shell函数

shell 函数也不像其它的函数。顾名思义，它的参数应该就是操作系统 Shell 的命令。它和 
反引号“`”是相同的功能。这就是说，shell函数把执行操作系统命令后的输出作为函数 
返回。于是，我们可以用操作系统命令以及字符串处理命令awk，sed等等命令来生成 
一个变量，如：

contents := $(shell cat foo)

files := $(shell echo *.c)

注意，这个函数会新生成一个Shell程序来执行命令，所以你要注意其运行性能，如果 
你的Makefile中有一些比较复杂的规则，并大量使用了这个函数，那么对于你的系统 
性能是有害的。特别是Makefile的隐晦的规则可能会让你的shell函数执行的次数比你 
想像的多得多。

import os
import tempfile

filename1 = tempfile.mktemp (".txt")
open (filename1, "w").close ()
filename2 = filename1 + ".copy"
print filename1, "=>", filename2

#拷文件
os.system ("copy %s %s" % (filename1, filename2))

if os.path.isfile (filename2): print "Success"

dirname1 = tempfile.mktemp (".dir")
os.mkdir (dirname1)
dirname2 = dirname1 + ".copy"
print dirname1, "=>", dirname2

#拷目录
os.system ("xcopy /s %s %s" % (dirname1, dirname2))

if os.path.isdir (dirname2): print "Success"

2. shutil.copy和shutil.copytree

import os
import shutil
import tempfile

filename1 = tempfile.mktemp (".txt")
open (filename1, "w").close ()
filename2 = filename1 + ".copy"
print filename1, "=>", filename2

#拷文件
shutil.copy (filename1, filename2)

if os.path.isfile (filename2): print "Success"

dirname1 = tempfile.mktemp (".dir")
os.mkdir (dirname1)
dirname2 = dirname1 + ".copy"
print dirname1, "=>", dirname2

#拷目录
shutil.copytree (dirname1, dirname2)

if os.path.isdir (dirname2): print "Success"

3.  win32file.CopyFile

import os
import win32file
import tempfile

filename1 = tempfile.mktemp (".txt")
open (filename1, "w").close ()
filename2 = filename1 + ".copy"
print filename1, "=>", filename2

#拷文件
#文件已存在时，1为不覆盖，0为覆盖
win32file.CopyFile (filename1, filename2, 1)
win32file.CopyFile (filename1, filename2, 0)
win32file.CopyFile (filename1, filename2, 1)

if os.path.isfile (filename2): print "Success"

dirname1 = tempfile.mktemp (".dir")
os.mkdir (dirname1)
dirname2 = dirname1 + ".copy"
print dirname1, "=>", dirname2

#拷目录
win32file.CopyFile (dirname1, dirname2, 1)

if os.path.isdir (dirname2): print "Success"

4. SHFileOperation 

import os
from win32com.shell import shell, shellcon
import tempfile

filename1 = tempfile.mktemp (".txt")
open (filename1, "w").close ()
filename2 = filename1 + ".copy"
print filename1, "=>", filename2

#拷文件
#文件已存在时，shellcon.FOF_RENAMEONCOLLISION会指示重命名文件
shell.SHFileOperation (
  (0, shellcon.FO_COPY, filename1, filename2, 0, None, None)
)
shell.SHFileOperation (
  (0, shellcon.FO_COPY, filename1, filename2, shellcon.FOF_RENAMEONCOLLISION, None, None)
)
shell.SHFileOperation (
  (0, shellcon.FO_COPY, filename1, filename2, 0, None, None)
)

if os.path.isfile (filename2): print "Success"

dirname1 = tempfile.mktemp (".dir")
os.mkdir (dirname1)
dirname2 = dirname1 + ".copy"
print dirname1, "=>", dirname2

#拷目录
shell.SHFileOperation (
  (0, shellcon.FO_COPY, dirname1, dirname2, 0, None, None)
)

if os.path.isdir (dirname2): print "Success"

不知道有没有其它的了，os.rename不算，那个是移动文件。另外我在测试它们的性能如何。
http://timgolden.me.uk/python/win32_how_do_i/copy-a-file.html 
这里和楼主列出的都一样，没有更多的了 
或者使用Chilkat  http://www.chilkatsoft.com/refdoc/pythonCkFileAccessRef.html

测试结果出来了： 
 测试环境：系统——Win7 RTM，CPU——P4 3.0，MEM——1.5G DDR400，U盘——Kingston 4G 
  
 用4种不同的方法从硬盘拷贝MSDN 2008 SP1（2.37G）到U盘： 
  
 os System      的方法耗时903.218秒 
 shutil         的方法耗时1850.634秒 
 win32file      的方法耗时861.438秒 
 SHFileOperation的方法耗时794.023秒 
  
 另外SHFileOperation是显示对话框的，可以这样用 

shell.SHFileOperation (
  (0, shellcon.FO_COPY, filename1, filename2, 
   shellcon.FOF_RENAMEONCOLLISION | \
   shellcon.FOF_NOCONFIRMATION |\
   shellcon.FOF_NOERRORUI | \
   shellcon.FOF_SILENT, None, None)
)

secname和contents是必须的，其他的都是可选的。下面挑几个常用的看看：

88888888**********************************

r与adr的区别

转自：http://coon.blogbus.com/logs/2738861.html

        ldr     r0, _start

        adr     r0, _start

        ldr     r0, =_start

        nop

        mov     pc, lr

_start:

        nop

编译的时候设置 RO 为 0x0c008000

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

0c008000 <_start-0x14>:

c008000:       e59f000c        ldr     r0, [pc, #12]   ; c008014 <_start>

c008004:       e28f0008        add     r0, pc, #8      ; 0x8

c008008:       e59f0008        ldr     r0, [pc, #8]    ; c008018 <_start+0x4>

c00800c:       e1a00000        nop                     (mov r0,r0)

c008010:       e1a0f00e        mov     pc, lr

0c008014 <_start>:

c008014:       e1a00000        nop                     (mov r0,r0)

c008018:       0c008014        stceq   0, cr8, [r0], -#80

分析：

ldr     r0, _start

从内存地址 _start 的地方把值读入。执行这个后，r0 = 0xe1a00000

adr     r0, _start

取得 _start 的地址到 r0，但是请看反编译的结果，它是与位置无关的。其实取得的时相对的位置。例如这段代码在 0x0c008000 运行，那么 adr r0, _start 得到 r0 = 0x0c008014；如果在地址 0 运行，就是 0x00000014 了。

ldr     r0, =_start

这个取得标号 _start 的绝对地址。这个绝对地址是在 link 的时候确定的。看上去这只是一个指令，但是它要占用 2 个 32bit 的空间，一条是指令，另一条是 _start 的数据（因为在编译的时候不能确定 _start 的值，而且也不能用 mov 指令来给 r0 赋一个 32bit 的常量，所以需要多出一个空间存放 _start 的真正数据，在这里就是 0x0c008014）。

因此可以看出，这个是绝对的寻址，不管这段代码在什么地方运行，它的结果都是 r0 = 0x0c008014

powercfg -energy

顺便找了一些powercfg的其他命令行选项在下面：

powercfg [-l] [-q ] [-x] [-changename] [-duplicatescheme] [-d] [-deletesetting] [-setactive] [-getactivescheme] [-setacvalueindex] [-setdcvalueindex] [-h] [-a] [-devicequery] [-deviceenablewake] [-devicedisablewake] [-import] [-export] [-lastwake] [-?][-aliases] [-setsecuritydescriptor] [-getsecuritydescriptor]

1） RSDP位于F段，用于OSPM搜索ACPI Table，RSDP可以定位其他所有ACPI Table

2） FACS位于ACPI NVS内存，用于系统进行S3保存的恢复指针，内存为NV Store

3） 剩下所有ACPI Table都位于ACPI Reclaim内存，进入OS后，内存可以释放

           ACPI Table根据版本又分为1.0B，2.0，3.0，4.0。2.0以后，支持了64-bit的地址空间，因此几个重要的Table会不大一样，比如：RSDP，RSDT，FADT，FACS。简单的列举一下不同版本的ACPI Table：

1） ACPI 1.0B：RSDP1，RSDT，FADT1，FACS1，DSDT，MADT，SSDT，HPET，MCFG等

2） ACPI 3.0 ：RSDP3，RSDT，XSDT，FADT3，FACS3，DSDT，MADT，HPET，MCFG，SSDT等

以系统支持ACPI3.0为例子，说明系统中ACPI table之间的关系如图：

 其中绿色代表在内存F段，蓝色是ACPI Reclaim内存，红色是NV store内存

1．函数指针定义

函数类型 （*指针变量名）(形参列表)；

“函数类型”说明函数的返回类型，由于“()”的优先级高于“*”,所以指针变量名外的括号必不可少，后面的“形参列表”表示指针变量指向的函数所带的参数列表。

例如：

int (*f)(int x);

double (*ptr)(double x);

在定义函数指针时请注意：
   
函数指针和它指向的函数的参数个数和类型都应该是—致的；

函数指针的类型和函数的返回值类型也必须是一致的。

2．函数指针的赋值

函数名和数组名一样代表了函数代码的首地址，因此在赋值时，直接将函数指针指向函数名就行了。

例如，

int func(int x);   /* 声明一个函数 */

int (*f) (int x);    /* 声明一个函数指针 */

f=func;            /* 将func函数的首地址赋给指针f */

赋值时函数func不带括号，也不带参数，由于func代表函数的首地址，因此经过赋值以后，指针f就指向函数func(x)的代码的首地址。

3．通过函数指针调用函数

函数指针是通过函数名及有关参数进行调用的。

与其他指针变量相类似，如果指针变量pi是指向某整型变量i的指针，则*p等于它所指的变量i；如果pf是指向某浮点型变量f的指针，则*pf就等价于它所指的变量f。同样地，*f是指向函数func(x)的指针，则*f就代表它所指向的函数func。所以在执行了f=func;之后，(*f)和func代表同一函数。

由于函数指针指向存储区中的某个函数，因此可以通过函数指针调用相应的函数。现在我们就讨论如何用函数指针调用函数，它应执行下面三步：

首先，要说明函数指针变量。

例如：int (*f)(int x);

其次，要对函数指针变量赋值。

例如： f=func;    (func(x)必须先要有定义)

最后，要用 (*指针变量)(参数表);调用函数。

例如：    (*f)(x);(x必须先赋值)

【例】任意输入n个数，找出其中最大数，并且输出最大数值。

main()

{

        int f();

        int i，a，b;

        int (*p)();    /* 定义函数指针 */

        scanf("%d"，&a);

        p=f;            /* 给函数指针p赋值，使它指向函数f */

        for(i＝1;i<9;i++)

        {
                scanf("%d"，&b);

                a＝(*p)(a，b);    /* 通过指针p调用函数f */

        }

        printf("The Max Number is:%d"，a)

}

f(int x，int y)

{

    int z;

    z＝(x>y)?x:y;

    return(z);

}

运行结果为：

343 -45 4389 4235 1 -534 988 555 789↙

The Max Number is：4389

【指针函数】

一个函数不仅可以带回一个整型数据的值，字符类型值和实型类型的值，还可以带回指针类型的数据，使其指向某个地址单元。

        返回指针的函数，一般定义格式为：

        类型标识符    *函数名(参数表)

int *f(x，y);

其中x，y是形式参数，f是函数名，调用后返回一个指向整型数据的地址指针。f(x，y)是函数，其值是指针。

如：char *ch();表示的就是一个返回字符型指针的函数，请看下面的例题：

【例】将字符串1(str1)复制到字符串2(str2)，并输出字符串2.

#include "stdio.h"

main()

{

    char *ch(char *，char *);

    char str1[]="I am glad to meet you!";

    char str2[]="Welcom to study C!";

    printf("%s"，ch(str1，str2));

}

char *ch(char *str1，char *str2)

{

    int i;

    char *p;

    p=str2
   
    if(*str2==NULL) exit(-1);

    do

    {

        *str2=*str1;

        str1++;

        str2++;

    }while(*str1!=NULL);

    return(p);

}

通过分析可得

函数指针是一个指向函数的指针，而指针函数只是说明他是一个返回值为指针的函数，

函数指针可以用来指向一个函数。

The following map varies in size and locus

	07C0:0		Boot code is loaded here at startup (31k mark)
A000:0		EGA/VGA RAM for graphics display mode 0Dh & above
B000:0		MDA RAM, Hercules graphics display RAM
B800:0		CGA display RAM
C000:0		EGA/VGA BIOS ROM (thru C7FF)
C400:0		Video adapter ROM space
C600:0 256bytes PGA communication area
C800:0	 16K	Hard disk adapter BIOS ROM
C800:5		XT Hard disk ROM format, AH=Drive, AL=Interleave
D000:0	 32K	Cluster adapter BIOS ROM
D800:0		PCjr conventionalsoftware cartridge address
E000:0	 64K	Expansion ROM space (hardwired on AT)
128K	PS/2 System ROM (thru F000)
F000:0		System monitor ROM
PCjr: software cartridge override address
F400:0		System expansion ROMs
F600:0		IBM ROM BASIC (AT)
F800:0		PCjr software cartridge override address
FC00:0		BIOS ROM
FF00:0		System ROM
FFA6:E		ROM graphics character table
FFFF:0		ROM bootstrap code
FFFF:5 8 bytes	ROM date (not applicable for all clones)
FFFF:E	byte	ROM machine id	(see MACHINE ID)

标志位   值为1    值为0
OF         OV       NV
SF          NG       PL
ZF          ZR       NZ
PF          PE       PO
CF          CY       NC
DF          DN      UP

PM是处理器的native模式，在这种模式下，处理器支持所有的指令和所有的体系结构特性，提供最高的性能和兼容性。对于所有的新型应用程序和操作系统来说，建议都使用这种模式。为了保证PM的兼容性，处理器允许在受保护的，多任务的环境下执行RM程序。这个特性被称做虚拟8086模式（Virtual-8086 Mode），尽管它并不是一个真正的处理器模式。Virtual-8086模式实际上是一个PM的属性，任何任务都可以使用它。

RM提供了Intel 8086处理器的编程环境，另外有一些扩展（比如切换到PM或SMM的能力）。当主机被Power-up或Reset后，处理器处于RM下。

SMM是一个对所有Intel处理器都统一的标准体系结构特性。出现于Intel386 SL芯片。这个模式为OS实现平台指定的功能（比如电源管理或系统安全）提供了一种透明的机制。当外部的SMM interrupt pin（SMI#）被激活或者从APIC（Advanced Programming Interrupt Controller）收到一个SMI，处理器将进入SMM。在SMM下，当保存当前正在运行程序的整个上下文（Context）时，处理器切换到一个分离的地址空间。然后SMM指定的代码或许被透明的执行。当从SMM返回时，处理器将回到被系统管理中断之前的状态。

由于机器在Power-up或Reset之后，处理器处于RM状态，而对于Intel 80386以及其后的芯片，只有使用PM才能发挥出最大的作用。所以我们就面临着一个从RM切换到PM的问题。

本文不讨论SMM，本节的重点集中于在Booting阶段如何从RM切换到PM，这里不会过多的讨论PM的细节，因为《Intel Architecture Software Developer’s Manual Volume 3: System Programming》中有非常详尽和准确的介绍。

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）所揭示的，它是全局可见的，对任何一个任务而言都是这样。

除了GDT之外，IA-32还允许程序员构建与GDT类似的数据结构，它们被称作LDT（Local Descriptor Table），但与GDT不同的是，LDT在系统中可以存在多个，并且从LDT的名字可以得知，LDT不是全局可见的，它们只对引用它们的任务可见，每个任务最多可以拥有一个LDT。另外，每一个LDT自身作为一个段存在，它们的段描述符被放在GDT中。

IA-32为LDT的入口地址也提供了一个寄存器LDTR，因为在任何时刻只能有一个任务在运行，所以LDT寄存器全局也只需要有一个。如果一个任务拥有自身的LDT，那么当它需要引用自身的LDT时，它需要通过LLDT将其LDT的段描述符装入此寄存器。LLDT指令与LGDT指令不同的时，LGDT指令的操作数是一个32-bit的内存地址，这个内存地址处存放的是一个32-bit GDT的入口地址，以及16-bit的GDT Limit。而LLDT指令的操作数是一个16-bit的选择子，这个选择子主要内容是：被装入的LDT的段描述符在GDT中的索引值——这一点和刚才所讨论的通过段积存器引用段的模式是一样的。

LDT只是一个可选的数据结构，你完全可以不用它。使用它或许可以带来一些方便性，但同时也带来复杂性，如果你想让你的OS内核保持简洁性，以及可移植性，则最好不要使用它。

引用GDT和LDT中的段描述符所描述的段，是通过一个16-bit的数据结构来实现的，这个数据结构叫做Segment Selector——段选择子。它的高13位作为被引用的段描述符在GDT/LDT中的下标索引，bit 2用来指定被引用段描述符被放在GDT中还是到LDT中，bit 0和bit 1是RPL——请求特权等级，被用来做保护目的，我们这里不详细讨论它。

前面所讨论的装入段寄存器中作为GDT/LDT索引的就是Segment Selector，当需要引用一个内存地址时，使用的仍然是Segment:Offset模式，具体操作是：在相应的段寄存器装入Segment Selector，按照这个Segment Selector可以到GDT或LDT中找到相应的Segment Descriptor，这个Segment Descriptor中记录了此段的Base Address，然后加上Offset，就得到了最后的内存地址。如下图所示：

2. Setup GDT

由上一节的讨论得知，GDT是Protected Mode所必须的数据结构，那么我们在进入Protected Mode之前，必须设定好GDT，并通过LGDT将其装入相应的寄存器。

尽管GDT允许被放在内存的任何位置，但由于GDT中的元素——描述符——都是64-bit长，也就是说都是8个字节，所以为了让CPU对GDT的访问速度达到最快，我们应该将GDT的入口地址放在以8个字节对齐，也就是说是8的倍数的地址位置。

GDT中第一个描述符必须是一个空描述符，也就是它的内容应该全部为0。如果引用这个描述符进行内存访问，则是产生General Protection异常。

如果一个OS不使用虚拟内存，段模式会是一个不错的选择。但现代OS没有不使用虚拟内存的，而实现虚拟内存的比较方便和有效的内存管理方式是页式管理。但是在IA-32上如果我们想使用页式管理，我们只能使用段页式——没有方法可以完全禁止段模式。但我们可以尽力让段的效果降低的最小。

IA-32提供了一种被称作“Basic Flat Model”的分段模式可以达到这种效果。这种模式要求在GDT中至少要定义两个段描述符，一个用来引用Data Segment，另一个用来引用Code Segment。这2个Segment都包含整个线性空间，即Segment Limit = 4 GB，即使实际的物理内存远没有那么多，但这个空间定义是为了将来由页式管理来实现虚拟内存。

在这里，我们只是处于Booting阶段，所以我们只需要初步设置一下GDT，等真正进入Protected Mode，启动了OS Kernel之后，具体OS打算如何设置GDT，使用何种内存管理模式，由Kernel自身来设置，Booting只需要给Kernel的数据段和代码段设置全部线性空间就可以了。

段描述符的格式如下图所示：

具体到代码段和数据段，它们的格式如下图所示：

下面就是在Booting阶段为进入Protected Mode而设置的临时的gdt。这里定义了3个段描述符：第一个是系统规定的空描述符，第2个是引用4 GB线性空间的代码段，第3个是引用4 GB线性空间的数据段。这是"Basic Flat Model"所要求的最下GDT设置，但就booting阶段，只是为了进入Protected Mode，并为内核提供一个连续的，最大的线性空间这个目的而言，已经足够了。

# Descriptor tables

gdt:
.word 0, 0, 0, 0 # dummy

.word 0xFFFF # 4Gb - (0x100000*0x1000 = 4Gb)
.word 0 # base address = 0
.word 0x9A00 # code read/exec
.word 0x00CF # granularity = 4096, 386
# (+5th nibble of limit)

.word 0xFFFF # 4Gb - (0x100000*0x1000 = 4Gb)
.word 0 # base address = 0
.word 0x9200 # data read/write
.word 0x00CF # granularity = 4096, 386
# (+5th nibble of limit)

3. Load GDT

设置好GDT之后，我们需要通过LGDT指令将设定的gdt的入口地址和gdt表的大小装入GDTR寄存器。

GDTR寄存器包括两部分：32-bit的线性基地址，以及16-bit的GDT大小（以字节为单位）。需要注意的是，对于32-bit线性基地址，必须是32-bit绝对物理地址，而不是相对于某个段的偏移量。而我们在Booting阶段，在进入Protected Mode之前，我们CS和DS设置很可能不是0，所以我们必须计算出gdt的绝对物理地址。

为了执行LGDT指令，你需要把这两部分内容放在内存的某个位置，然后将这个位置的内存地址作为操作数传递给LGDT指令。然后LGDT指令会自动将保存在这个位置的这两部分值装入GDTR寄存器。

# 这是存放GDTR所需的两部分内容的位置

gdt_48:
.word 0x8000 # gdt limit=2048,

# 256 GDT entries

.word 0, 0 # gdt base (filled in later)

# 下面这段代码用来计算GDT的32-bit线性地址，并将其装入GDTR寄存器。

xorl %eax, %eax # Compute gdt_base
movw %ds, %ax # (Convert %ds:gdt to a linear ptr)
shll $4, %eax
addl $gdt, %eax
movl %eax, (gdt_48+2)
lgdt gdt_48 # load gdt with whatever is appropriate

4. Other Preparing Stuff

在进入Protected Mode之前，除了需要设置和装入GDT之外，还需要做如下一些事情：
屏蔽所有可屏蔽中断；
装入IDTR；
所有协处理器被正确的Reset。
由于在Real Mode和Protected Mode下的中断处理机制有一些不同，所以在进入Protected Mode之前，务必禁止所有可屏蔽中断，这可以通过下面两种方法之一：

使用CLI指令；
对8259A可编程中断控制器编程以屏蔽所有中断。
即使当我们进入Protected Mode之后，也不能马上将中断打开，这时因为我们必须在OS Kernel中对相关的Protected Mode中断处理所需的数据结构正确的初始化之后，才能打开中断，否则会产生处理器异常。

在Real Mode下，中断处理使用IVT(Interrupt Vector Table)，在Protected Mode下，中断处理使用IDT（Interrupt Descriptor Table），所以，我们必须在进入Protected Mode之前设置IDTR。

IDTR的格式和GDTR相同，IDTR的装入方式和GDTR也相同。由于IDT中相关的中断处理程序需要让OS Kernel来设定，所以在Booting阶段，我们只需要将IDTR中IDT的基地址和Size都设为0就可以了，随后，等进入Protected Mode之后，由OS Kernel来真正设置它。

关于中断机制和中断处理，请参考 Interrupt & Exception ，这里不再赘述。

#

# 这是存放IDTR所需的两部分内容的位置

#

idt_48:
.word 0 # idt limit = 0
.word 0, 0 # idt base = 0L

# 对于IDTR的处理，只需要这一条指令即可

lidt idt_48 # load idt with 0,0

#

# 通过设置8259A PIC，屏蔽所有可屏蔽中断

#

movb $0xFF, %al # mask all interrupts for now
outb %al, $0xA1
call delay

movb $0xFB, %al # mask all irq's but irq2 which
outb %al, $0x21 # is cascaded

# 保证所有的协处理都被正确的Reset

xorw %ax, %ax
outb %al, $0xf0
call delay

outb %al, $0xf1
call delay

# Delay is needed after doing I/O

delay:
outb %al,$0x80
ret

5. Let's Go

好了，一切准备就绪，Fire!:)

进入Protected Mode，还是进入Real Mode，完全靠CR0寄存器的PE标志位来控制：如果PE=1，则CPU切换到PM，否则，则进入RM。

设置CR0-PE位的方法有两种：

第一种是80286所使用的LMSW指令，后来的80386及更高型号的CPU为了保持向后兼容，都保留了这个指令。这个指令只能影响最低的4 bit，即PE，MP，EM和TS，对其它的没有影响。

#

#通过LMSW指令进入Protected Mode

#

movw $1, %ax # protected mode (PE) bit

lmsw %ax # This is it!

第二种是Intel所建议的在80386以后的CPU上使用的进入PM的方式，即通过MOV指令。MOV指令可以设置CR0寄存器的所有域的值。

#

#通过MOV指令进入Protected Mode

#

movl %cr0, %eax

xorb $1, %al # set PE = 1

movl %eax, %cr0 # go!!

OK，现在已经进入Protected Mode了。

很简单，right？But It's not over yet!

6. Start Kernel

我们已经从Real Mode进入Protected Mode，现在我们马上就要启动OS Kernel了。

OS Kernel运行在32-bit段模式，而当前我们却仍然处于16-bit段模式。这是怎么回事？为了了解这个问题，我们需要仔细探讨一下IA-32的段模式的实现方法。

IA-32共提供了6个16-bit段寄存器：CS，DS，SS，ES，FS，GS。但事实上，这16-bit只是对程序员可见的部分，但每个寄存器仍然包括64-bit的不可见部分。

可见部分是为了供程序员装载段寄存器，但一旦装载完成，CPU真正使用的就只是不可见部分，可见部分就完全没有用了。

不可见部分存放的内容是什么？具体格式我没有看到相关资料，但可以确定的是隐藏部分的内容和段描述符的内容是一致的（请参考段描述的格式），只不过格式可能不完全相同。但格式对我们理解这一点并不重要，因为程序员不可能能够直接操作它。

我们以CS寄存器为例，对于其它寄存器也是一样的：

在Real Mode下，当我们执行一个装载CS寄存器的指令的时候（jmp，call，ret等），相关的值会被装入CS寄存器的可见部分，但同时CPU也会根据可见部分的内容来设置不可见部分。比如我们执行"ljmp $0x1234, $go "之后，CS寄存器的可见部分的内容就是1234h，同时，不可见部分的32-bit Base Address域被设置为00001234h，20-bit的Limit域被设置为固定值10000h，也就是64 KB，Access Information部分的其它值我们不去考虑，只考虑其D/B位，由于执行此指令时处于Real Mode模式，所以D/B被设置为0，表示此段是一个16-bit段。当对CS寄存器的可见部分和不可见部分的内容都被设置之后，CS寄存器的装载工作完成。随后当CPU需要通过CS的内容进行地址运算的时候，则仅仅引用不可见部分。

在Protected Mode下，当我们执行一个装载CS寄存器的指令的时候，段选择子（Segment Selector）被装入CS寄存器的可见部分，同时CPU根据此选择子到相应的描述符表中（GDT或LDT）找到相应的段描述符并将其内容装载入CS寄存器的不可见部分。随后CPU当需要通过CS的内容进行地址运算的时候，也仅仅引用不可见部分。

从上面的描述可以看出，事实上CPU在引用段寄存器的内容进行地址运算时，Real Mode和Protected Mode是一致的。另外，也明白了为什么我们在Real Mode下设置的段寄存器的内容到了Protected Mode下仍然引用的是16-bit段。

那么我们如何将CS设置为引用32-bit段？方法就像我们前面所讨论的，使用jmp或call指令，引用一个段选择子，到GDT中装载一个引用32-bit段的段描述符。

需要注意的是，如果CS寄存器的内容指出当前是一个16-bit段，那么当前的地址模式也就是16-bit地址模式，这与你当前是出于Real Mode还是Protected Mode无关。而我们装载32-bit段的jmp指令或call指令必须使用的是32-bit地址模式。而我们当前的boot部分代码是16-bit代码，所以我们必须在此jmp/call指令前加上地址转换前缀代码66h。

下面的例子就是使用jmp指令装入32-bit段。Jmpi指令的含义是段间跳转，其Opcode为Eah，其格式为：jmpi Offset, Segment Selector。

# 由于当前的代码是16-bit代码，而我们要执行32-bit地址模式的指令，指令前

# 需要有地址模式切换前缀66h，如果我们直接写jmp指令，由编译器来生成代码

# 的话，是无法作到这一点的，所以我们直接写相关数据。

　 .byte 0x66, 0xea # prefix + jmpi-opcode

　 .long 0x1000 　# Offset
　 .word __KERNEL_CS　# CS segment selector

上面的代码相当于32-bit指令：

jmpi 0x1000,__KERNEL_CS

如果__KERNEL_CS段选择子所引用的段描述符设置的段空间为线形地址[0，4 GB]，而我们将OS Kernel放在物理地址1000h，那么此jmpi指令就跳转到OS Kernel的入口处，并开始执行它。

此时，Booting阶段结束，OS正式开始运行！

Table 1 lists the system resources and associated I/O addresses that should not be directly accessed by BIOS AML code (the "blocked ports" list).

Table 1 Blocked I/O Port Addresses and System Board Resources

*Read or write accesses to these ports are always blocked, regardless of the BIOS use of the _OSI method.