![](https://img-blog.csdnimg.cn/20201014180756724.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
操作系统Ucore
文章平均质量分 84
操作系统Ucore
zzzzzec
这个作者很懒,什么都没留下…
展开
-
操作系统Ucore:Lab2内存管理(六)
进入Lab2,Lab2的主要内容是内存的管理0.新的bug按照文档上的说明,我们要把lab1中写的代码复制到Lab2中。我一开始并不想这样做,因为我想保留我在Lab1中写的注释,所以我就merge了lab2到lab1中,经过了艰难的处理冲突之后,make qemu 。但悲剧的是qemu的控制台没有输出,我仔细的再次比对代码,还是没有找出为什么。无奈之下,只好复制lab1的代码到lab2…但这还没完源代码中由好几个像注释部分这样初始化的位置,但是我前文已经验证了这样是无法正常初始化的啊…用gdb看这原创 2021-12-11 22:04:32 · 637 阅读 · 0 评论 -
操作系统Ucore:Lab1QA(五)
来回答一下Lab1的问题练习1:理解通过make生成执行文件的过程。1.1操作系统镜像文件ucore.img是如何一步一步生成的?ucore.img由kernel的bootblock组成,bootblock由bootasm和bootmain编译生成,最后由sign.c填充。kernel则由kern目录下的文件编译而成。最后使用dd命令构造ucore.img1.2一个被系统认为是符合规范的硬盘主引导扇区的特征是什么?最后两个字节是0x55AA练习2:使用qemu执行并调试lab1中的软件。跳过原创 2021-12-02 11:10:38 · 1316 阅读 · 0 评论 -
操作系统实验Ucore:Kernel_init(四)
本文首发于我的博客上一节进行到了kernel_init的printf_kernelinfo,继续往下分析1.pmm_init这个函数,顾名思义是用来初始化物理内存的函数,这个函数只会调用gdt_init()这里我稍微修改了一下代码框架,原本的gdt_pd的定义为注释部分这段代码看上去没问题,但是实际跑的时候就会发现gdt_pd的两个字段都是0。我写了一个程序来模拟这种情况,看上去好像没有问题,但这个程序是无法通过编译的。这个错误告诉我们编译器无法在执行前算出a1的地址。所以不可以这样初原创 2021-12-01 14:57:02 · 548 阅读 · 0 评论 -
操作系统实验Ucore:kernel_init(三)
本文首发于我的博客1.进入Kernel_init()从bootmain加载完ELF之后,就会跳转到0x100000位置,这里即kernel_init函数所在的位置先看第一部分,这里开头就有两个变量 edata 和 end,首先他们的类型是一个指向char数组的指针,其次,由于使用了extern关键字,代表这两个变量在其他位置定义,那么问题就在于到底是在哪里定义的呢。找遍了所有的代码都没有找到哪里有定义这些变量…终于,在链接脚本里边找到了这里使用了PROVIDE关键字,简而言之,这个关键字可以在链接原创 2021-11-30 15:03:52 · 485 阅读 · 0 评论 -
操作系统实验Ucore:Bootasm启动(一)
此文章首发于我的博客:我的博客,博客上的排版更好一些…首先,先放一张我画的Bootasm阶段(调用bootmain之前)的内存分布图注:这个内存分布图只标识了大概位置,并没有考虑对齐在此基础上,再来分析ucore的启动代码1.启动地址首先我们要知道第一条指令的地址在哪,当然,第一条指令指的时操作系统执行的指令。根据上图的描述,第一条指令的地址是0x7c00.在makefile中,这一段程序指定了bootblock的入口函数为 start,其实地址为 0x7c00.使用gdb 调试可以很容易的原创 2021-11-28 17:45:55 · 328 阅读 · 0 评论 -
操作系统实验Ucore:bootmain(二)
本文首发于我的博客书接上回,我们继续来看ucore操作系统的启动部分。上一部分结束时,程序已经从最开始的bootasm跳转到了bootmain函数。1. 读取磁盘由于BIOS只会把第一个扇区加载到磁盘上,而我们的操作系统的大小肯定不止512KB,所以要在boot程序中把操作系统其余的部分加载到内存上。总体来看,这个函数的意思就是将磁盘上从1开始的8个扇区加载到ELFHDR(0x1_0000)的位置上。由于第0个扇区(就是我们现在正在执行的代码)已经被BIOS加载上了,所以从第一个扇区开始加载就行原创 2021-11-29 11:23:54 · 454 阅读 · 0 评论