首先,ucore需要建立一个空的栈空间,然后才能进行函数调用、参数传递等处理工作。ucore是在哪里建立的栈呢?其实ucore是借用了bootloader的栈空间,而bootloader在bootasm.S中的如下语句建立的栈空间: # Set up the stack pointer and call into C. movl $0x0, %ebp movl $start, %esp
可以看到bootloader把栈底设置到了$start地址处,正好是bootloader的起始地址0x7c00。不过由于入栈操作中的esp是向下增长的,所以不会覆盖bootloader的内容。那ebp有何作用呢?我们先暂时放在一边,继续跟踪代码的执行。
接下来,bootloader会调用bootmain()函数,而bootmain()函数会在加载完ucore后,调用ucore的起始函数kern_init()。在ucore的继续执行过程中,还将有如下的函数调用过程:
kern_init-->monitor-->runcmd-->mon_backtrace-->print_stackframe。
这通过看源代码或执行monitor中的backtrace命令都可以了解到。
我们可以结合前面的实验来说明ucore是如何分析出这样的调用关系的。
操作系统中的中断(也称异常)技术是操作系统的重要功能,是计算机硬件和软件相配合产生的重要技术。简单地说,中断处理是指由于有紧急事件产生,需要打断当前CPU的正常执行,转而处理紧急事件,处理完毕后,恢复到被打断的地方继续执行。通过中断机制,计算机系统可以高效地处理外设请求,可以快速响应应用软件的异常或请求,也可以有规律地打断应用程序的执行,把执行CPU控制权还到操作系统手中,从而使得整个计算机系统的资源可控。但单纯的操作系统原理书籍很难深入分析中断的处理细节。我们希望通过后续的proj4/4.1.1等的实验,让读者了解到ucore操作系统如何完成上述事情。
首先我们需要了解GCC生成的C函数调用过程:
-
调用函数为了传递参数给被调用函数,需要执行0到n个push指令把函数参数入栈,然后会执行一个call指令,在call指令内部执行过程中,还把返回地址(即CALL指令下一条指令的地址)也入栈了。
-
GCC编译器会在每个函数的起始部分插入类似如下指令(可参看obj/kernel.asm文件内容):
push %ebp mov %esp,%ebp sub $NUM,%esp
在ucore执行到一个函数的函数体时,已经有以下数据顺序入栈:调用函数的参数,函数返回地址。由此得到类似如下的栈结构(参数入栈顺序跟调用方式有关, 这里以C语言默认的CDECL为例):
高地址方向
|------------------------|
|------------------------| <-----------
| ......... |
| argument 3 | Caller's stack frame
| argument 2 |
| argument 1 |
| return address |<---------- esp
|------------------------|
| ......... |
低地址方向
“push %ebp”和“mov %esp,%ebp”这两条指令实在隐含了对函数调用关系链的建立:首先将ebp入栈,然后将栈顶指针esp赋值给ebp,此时的栈结构如下所示:
高地址方向 |
---|
------------------------<----------- |
......... |
argument 3 |
argument 2 |
argument 1 |
return address |
----previous ebp----- |
------------------------ |
......... |
低地址方向 |
“mov %esp,%ebp”这条指令表面上看是用esp把ebp的旧值覆盖了,但在这条语句之前,ebp旧值已经被压栈(位于栈顶),而新的ebp又恰恰指向栈顶。第三条语句“sub $NUM,%esp”把esp减少了NUM个值,这其实是建立了函数的局部变量、寄存器保存的空间。此时的栈结构如下所示:
高地址方向
|------------------------|
|------------------------<-----------
| ......... |
| argument 3 | Caller's stack frame
| argument 2 |
| argument 1 |
| return address |<-----------
|----previous ebp-----|<------ ebp, esp
|------------------------|
| ......... |
| saved registers |
| ......... | Current(Callee's) stacl frame
| local variables |
| …...... |
|----------------------- |<-------- esp
|------------------------|
| ......... |
低地址方向
到此时为止,ebp寄存器处于函数调用关系链中一个非常重要的地位。ebp寄存器中存储着栈中的一个地址(栈帧分界处),此地址是“老”ebp入栈后的栈顶。那么以该该地址为基准,向高地址方向(即栈底方向)能获取返回地址、参数值,向低地址方向(栈顶方向)能获取函数局部变量值,而该地址处又存放着上一层函数调用时的ebp值。由于ebp中的地址处总是“上一层函数调用时的ebp值”,这样,就能通过把ebp的内容作为寻找上一个调用函数的栈帧的指针,如此形成递归,直至到达栈底。这就可找到整个的函数调用栈。这也是kdebug.c中print_stackframe函数的实现内容。