- 博客(2145)
- 收藏
- 关注
RSS订阅原创 1660_MIT 6.828 JOS初始化boot_alloc的初步实现
这一行代码让分页管理的机制处理kern_pgdir虚拟地址的时候，把kern_pgdir的地址映射到kern_pgdir的物理地址上。这一次的小结有一点没底气，因为感觉实现的过于简单，可能跟正确的结果有一定的差距。这一段代码其实还是很容易理解的，end其实是链接文件中定义的，这个数值其实是内核所占用的存储的最后的地址。Panic的地址范围判断应该是KERNBASE空间之后的超过总的物理存储区的时候。PDX(UVPT)是一个获取页目录索引的方式，而处理的对象UVPT是用户虚拟页表，一个用户只读的用户页表。
2023-03-26 18:53:35
193
原创 1659_MIT 6.828 JOS存储初始化中的内核虚拟地址到物理地址的映射
这个空间的看见，看了前面的memlayout感觉也有了一定的思维模型可以参考了。而上面涉及到了这次调用中的第一个接口调用，i386_detect_memory()，这是一个很底层的判断，用来检查当前的系统可用的存储。首先需要知道的是KVA，内核虚拟地址的范围。这个地址其实就是软件编译之后链接器分配的地址，JOS把内核的部分分配到了KERNBASE + 1MB的位置。因此，上面的处理所获得的物理地址其实是一个1MB开始往后的地址。这样，可以想得出来，后续kern_pgdir的内容还是需要进行一定的处理的。
2023-03-25 19:41:51
2
原创 1658_MIT 6.828 JOS memmap以及一些存储划分定义的解读-第二部分
接下来的几个特殊区域是两个区。第一个4MB之中包含了USTABDATA，其实是从2MB的位置开始的，这只用掉了这一个大区中的一部分。而第二个区域中，错误处理其实用掉的空间比较小，只有一个页，4K，其他的全都是交换区应用。在用户可以完全操作的存储空间中，最上面先进行了 exception 的处理存储区域的划分，这个存储区域一共是2页 8K，实际的使用使用了4K，另外的一半处理机制跟上一次看到的内核的堆栈类似，加了一个无效数据区域作为防护区。之前，看到的UENVS的信息，这个地址是用户的只读区域的边界线了。
2023-03-25 19:38:34
388
原创 1657_MIT 6.828 JOS memmap以及一些存储划分定义的解读-第一部分
因为，我们的JOS在初始化的时候映射的存储只有两部分，第一个是0~4MB映射到0~4MB。中间跳过去的这部分参数其实很好理解了，在x86的设计中，最开始的一块地址是存储，一共640K。如果按照之前看到的OS的分页映射，这部分的线性地址其实是在KERNBASE开始的1MB范围之内。但是，这部分内容更加细致，除了说明用户的存储空间可用范围之外，还指出来了这里还有一些特殊的用户只读的信息区域。操作系统其实是被链接到了KERNBASE + 1MB的地址上的，也就是说从画出来的这部分继续向上的一部分空间中。
2023-03-25 19:34:52
293
原创 1656_MIT 6.828 JOS i386_init的实现分析
而这个无限循环的循环体，应该就是shell处理的过程，大概率跟我之前看到过的shell例程是相似的。存储的区间范围信息的获取，其实是通过链接文件来实现的。在BootLoader调用kernel之后，先执行一段entry.S的汇编代码，之后调用的i386_init函数进入到C语言的处理过程。这个之前已经测试过了，而通过前面的终端初始化中的错误处理其实是能够看得出来这个cprintf已经就绪了的。继续往下是存储的初始化，这部分已经做了一个初步的了解，主要的工作就是对存储的分页管理机制进行相应的配置准备。
2023-03-25 19:32:00
385
原创 1655_MIT 6.828 JOS存储分页映射的实现分析
如果，进行了一个减去KERNBASE的处理，其实里面的信息也就是在1MB这个地址附近，确切说是这个地址稍微往后一点的地方。这么看，在数值上entry_pgdir的第0个元素的数值应该是entry_pgtable数组在被BootLoader加载到物理存储之后的位置的一个字节之后的地址值。而这里面的第0x3c0个元素的数值则是比上面的数值再大2的一个数值。这样，对这段代码重新理解应该能够得出这样的基本推理信息：页目录表的index其实是需要处理的线性地址的高10bit，根据这个信息，可以索引到一个信息。
2023-03-25 19:28:02
302
原创 1654_MIT 6.828 JOS entry.S实现分析
内核在链接的时候会链接到一个指定地址（KERNBASE + 1M）开始的存储区，而BootLoader加载内核的时候会把内核加载到1M开始的存储区。这样，加载之后，内核镜像的信息其实是与链接中的信息差了一个KERNBASE的差距。从这个意义上讲，这个功能也就是在实际的物理存储中根据内核信息解析数据的时候会用到的一个转换。接下来看CR0控制寄存器，这里面的信息还是很多的，结合上面的表格，可以知道这一次的操作主要是做了这几个操作：1，开启了保护模式；从命名看，跟描述是符合的，这里存储的是页目录的地址信息。
2023-03-25 19:26:56
334
原创 1653_C语言在定义数组的时候指定某几个元素的初始值
如同结构体成员的初始化，其实我在初始化的时候是可以做到编写上的“乱序”的。这样的功能看起来暂时考虑不到有什么具体的用法会在我现在的工作中用上，不过至少给了我一点令人开心的信息：C语言的编码有些地方的确是非常有趣。既然只是联想猜测，那么验证的方式其实也很简单，要么去找对应的说明，可能会涉及到C标准，也可能得翻基本C教程。如果猜测的是准确的，那么打印出来的信息中，0、1、2、8应该对应着8、1、5、7的数值。如果支持乱序，首先这个编译应该是可以通过的，其次，应该输出与之前的代码完全一样的输出结果。
2023-03-25 19:18:57
4
原创 1652_MIT 6.828 shell例程重定向的实现分析
由此，当我们回到上面的重定向的case处理分支中的时候，相应的文件描述符的信息就应该有一个清晰的概念了。其实，通过反复的处理这里实现的处理只是巧妙地新创建文件描述符并且关闭之前的文件描述符来做一个概念上的切换。首先，通过新的open操作来对原来的文件进行了对等的flags等操作绑定了新的文件描述符。接着，关闭了原来的文件绑定的文件描述符，而这个绑定其实是标准的输入输出。重定向处理的是相关的文件，而文件处理完之后还需要按照普通的方式进行命令的调用。从上面的结果看，这个还是跟分析的内容一致的。
2023-03-25 19:16:25
329
原创 1651_MIT 6.828 dup函数的简单梳理
如果这是值得关注的，那么除非程序是单线程的，并且不在信号处理程序中分配文件描述符，否则正确的方法是在调用dup2（）之前不要关闭newfd，因为上面描述了竞争条件。Shell例程其实是一个很好的文件处理概念梳理的例程，里面涉及到了一些最基本的文件操作的理念。1. 多了一个指定参数的dup2，如果在输入的oldfd无效的时候会报错，但是指定新打开的文件描述符并不会关闭。4. dup2的功能在dup的基础上多了一个可以指定文件描述符数值的功能，而一般的文件描述符的分配规则则是采用当前没有使用的最小数值。
2023-03-25 19:12:37
373
原创 1650_MIT 6.828 open函数的简单梳理
这里介绍了几种flags的模式，这种模式其实是很容易理解的，也是我很熟悉的。1. 我所接触的shell实现中，接下来会用到的一个参数就是这里，其实是一个mode的概念。这里的creat（不知道为什么不把后面的e写上），其实是一个多种flags组合的open的等效方式。4. 这个函数的主要功能其实是把文件或者设备绑定成为一个文件描述符信息，这个也是unix中比较有趣的哲学思想：一切全都是文件。3. 这一组函数也是我看到的比较有趣的函数，之前没有什么印象有函数名在一个地方直接做两个不同的声明。
2023-03-25 19:12:14
321
原创 1649_Excel中删除重复的数据
而且，从大众化的角度来考虑，我们不见得很容易遇到所有的开发环境都就绪的电脑。或许，我们经常接触的电脑都有着较为完善的开发环境也只是因为我们的“工作圈”特殊，电脑的环境较为特殊而已。如果到了一个全新的环境，解决这样的问题，或许我们的技能就没有了用武之地了。我这里的例子找了一个相对简单的情况，其实B列有可能也是不一样的，也有对应的处理方式。我这次的整理过程，其实也只是这样的工作环境的一个复刻，并不是我原始处理的问题。选择上面的这个操作，按照自己的需要选择接下来的处理扩展的模式即可。
2023-03-21 20:20:31
123
原创 1648_MIT 6.828 shell例程中调用系统命令的实现
再者，需要注意到的是这个是测试的实现，文件的名称加上目录信息是有一个长度限制的。这个其实还得去看之前的命令解析部分，在这个命令解析的过程中其实是进行了参数的数组化的。这样的实现，是通过之前看过的exec系列函数来实现的。其实关于结束符的处理，之前我在看代码的时候还是看到了的，只是当时我并不是很清楚exec这一组函数，因此没有看明白这其中的意图。这个主要是在main中的while循环中实现的，这个输出绑定了命令的获取动作。前面已经学习了很多基本的函数实现，也进行了这个shell例程中的很多函数接口的分析。
2023-03-21 20:15:26
158
1
原创 1647_MIT 6.828 strcat函数的简单总结
这个，从处理的信息角度来说的确是跟我现在常用的嵌入式是很不相同的。4. 这里给出来了一种strncat的实现方式，这里可以看出来结束的条件有两种，要么是拷贝完字符串要么是拷贝了足够多的字符数目。1. 这里的这个测试代码，通过增加了一个时间监控信息能够让人感觉出来随着字符串的变长，拼接的速度是有变化的。这个是运行的效果，这里没有录制视频，不然是能够很明显体验到行切换的速度在逐渐变慢的过程。4. 在拼接的过程中需要判断dest的结束位置，这个过程会花费一定的时间，而且是跟字符串的长度有关的。
2023-03-20 07:15:25
31
原创 1646_MIT 6.828 exec函数的简单总结
3. 关于返回值这部分需要注意一下，虽说函数原型中有一个返回值int，但是这个函数其实存在两种情况：成功的时候直接不会返回，而失败的时候则会返回错误码，返回的错误码是-1。2. 这里的机组函数其实功能都是类似的，但是不同的函数使用的参数有所不同。以上就是这一组函数的基本介绍，其实了解这一组函数的用法只需要了解其中的一个函数即可，其他的函数是类似的，只是参数不同。1. 函数中的后缀带有v的，对应的参数参数的信息是一个vector，数组。1. 这个系列的函数主要还是POSIX的标准中要求的。
2023-03-19 21:15:14
131
原创 1645_MIT 6,828 shell例程中parseline以及parsepipe的实现
其中，组合的一个元素是前面已经提取出来的命令信息，另一个元素则是剩余部分作为管道命令处理的一个最终展开结果。由此我们甚至可以得出一个粗浅的抽象概念：普通的命令我们可以理解为是一种特殊的管道命令，这种管道命令无需进行左右命令的拆分组合。首先，看一下管道命令解析函数的实现。如果不是，那么说明至少当前的处理之中没有管道信息，提取出来的命令直接进行一个返回即可。这个组合其实是非常简单的，就是进行了两个命令的关联，同时标注了一下这个命令的类型为管道命令。这是管道命令数据结构定义的方式，可以用来辅助理解上面的实现。
2023-03-19 21:12:52
11
原创 1644_MIT 6.828 shell例程中parseexec函数的实现分析
而这个逻辑跳过了管道符号，又执行了一次gettoken的调用，会把接下来的一段参数字符串取出来。后面需要补充完才能够完成回溯的解读，这样，等待以后开启新的代码分析了。4. 在第3步的处理中，参数的字符串范围已经取出来了，在接下来的参数处理中通过mkcopy函数进行了字符串内容的复刻。继续看这个shell例程的分析，现在从最初的有点茫然到现在基本能够看清楚数据处理的流程了。而接下来的重定向处理，则是判断命令是否有重定向的动作，并且进行了命令的转换。因此，循环结构的存在是需要解决这样的问题的。
2023-03-19 21:11:14
251
原创 1643_MIT 6.828 shell例程中parseredirs函数的实现分析
而redircmd其实是进行了命令的重新组合，根据传入的文件名、定向类型对传入的命令进行重新包装。其实，最后返回的命令指针信息并不是一个重定向命令结构，但是两者由于存储排布有着很有规律的空间关系，因此进行二次解析也是很容易的。而命令解析的第一步，其实就是进行命令的重定向处理。由于传递的信息是一个地址，而这个地址后面的信息解析又有固定的空间相对关系，因此这样的接口是可以兼容两种不同的命令信息的。通过对函数实现的分析，结合函数的名称缩写，基本上可以知道这个函数实现的是命令重定向的解析。
2023-03-13 21:15:46
21
原创 1642_MIT 6.828 shell例程中gettoken函数的实现分析
现在看代码的过程中能够感觉到越来越顺利了，因为通过一个个函数的分析现在掌握的基本语素积累是越来越多了。同时，几个分支以及雷同的处理让我想到了之前看过的SICP的一些处理理念。前面分析peek的时候已经看过一些类似的处理了，因此这里的这一段代码一看其实哈市很容易理解的。看到这里的eq，结合前面的q基本上就知道这两个参数的作用了。如果不是上面的几个特殊字符，那么默认是把返回值标记为字符a，同时进行另一轮的去空白并且去、|这是哪个字符处理。上面的信息记录结束之后，对于剩余的字符进行了新的去除空白操作处理。
2023-03-13 21:13:45
24
原创 1640_MIT 6.828 fork函数的功能以及相关代码分析
1. 如果操作成功，那么父进程返回子进程的PID（标注的时候写错了），自己成返回0，而失败则返回1。再回到主函数部分分析这个shell的主要功能，跳过cd的处理之后可以知道，这个函数的循环其实是完成了一个命令获取成功之后的fork。2. 子进程的创建方式是通过复制调用它的进程来创建的，而父子进程的存储空间是独立的，子进程会有自己的PID、进程组编号以及会话。2. 关于细节性的信息这里给出来了太多，单纯的强行记忆没有什么很好的作用，这里的信息我决定先跳过去后续随着实际的应用来返回查找认证。
2023-03-11 12:24:52
280
原创 1641_strchr函数的功能分析以及peek功能实现分析
Peek会跳过字符串中的空白，这是上面第一个strchr的作用，用来甄别空白字符。甄别处理的过程中，peek其实是会直接修整原始的字符串。假如，这样的操作结束后字符串不是空，并且字符串的第一个字符是toks字符串的子集，那么返回1，否则返回0。4. strchr的作用是查找一个字符在字符串中的位置，找不到返回NULL；Strchrnull是GNU的一个扩展，这也就意味着上面提到额度BSD等一系列的标准实现中可能是不包含的。2. 这个函数，或者说这三个函数主要的功能是确认一个字符在字符串中的位置。
2023-03-11 12:24:36
301
原创 1639_perror的函数功能以及简单测试
这里不仔细看或许还以为是这个函数的返回值是-1，其实这里提到的则是系统调用的返回值。这是编译后运行的效果，从这里看这个错误消息输出的时候其实是自带着换行符号的。而前面提到的errno，有时候提供的信息也不一定是错误，成功也是其中的一种。1. 这个是我在看UNIX或者linux接口的时候看到的满足的标准比较多的一个接口了，看起来折腾操作系统最终的归宿其实还是少不了要跟这种标准打交道。2. 这个函数也是近期看到的比较适应于Linux的环境的了，没有之前看到的符合POSIX，linux实现可能略有不同的描述。
2023-03-11 12:17:43
315
原创 1638_chdir函数的功能
从整个程序的设计结构来看，其实是十分类似于嵌入式里面的一个简单的轮询处理的过程，整个处理过程就是在不断扫描处理的过程。1. 函数的接口功能就是切换工作目录，其实跟命令中的cd应该是基本类似的。然而，perl中的经典教程小骆驼中印象中提过，很多perl中的接口也不见得跟unix的接口有啥对等关系。最早接触这样的一个接口自然还是perl学习的时候，到了后面接触python也看到了类似的接口在os的模块之中。倒是之前看过的fork，不过这次看到的应该是一个全新的实现，这样后续单独做这个分析。
2023-03-10 23:00:55
543
原创 1637_fgets函数的功能
这样，结合这一次的接口分析以及之前看到的其他的接口内容就很容易理解上面的这个函数的设计了。4. 这个函数的功能是根据一个数据流获取一个字符串，而这个字符串的获取结束有几种条件，比如说到了指定的字节数或者换行符亦或者是文件的结束。但是，这次的这个函数应该是之前C语言的基本教程中存在的，只是我这么多年来一直做嵌入式软件的开发可能这方面不敏感，看到类似的功能章节会直接跳过。1. 这个文档的风格跟前面看到的几个接口的文档风格的确是不同，里面的内容详实程度要好很多。5. 这个接口在设计的时候是符合标准C的规范的。
2023-03-10 23:00:49
354
原创 1636_isatty函数的功能
看起来，后续类似的问题还会有很多。这样，对照着文档信息，这里的半个函数其实是可以看懂了的。既然是工作之余的兴趣学习，那么可以轻松自在一些，不去扩展那么多了，这个函数的学习留待下次。而SVr4是一个什么内容我之前是没有什么接触的，继续往深了看下去会是一个无底洞，因此暂且先了解这么多。这个是测试的效果，从这里看跟我前面看文档的时候分析的基本上是一样的。1. 首先，有了上一次的分析经验，因此从这个标注可以看得出来这个函数其实是一个库函数。这一页其实是没有什么值得看的信息的，这一个接口的文档内容还是比较少的。
2023-03-10 22:56:12
300
原创 1635_fileno的简单使用
其中，stderr是不带有缓冲的，stdout则是带有缓冲机制的。在看MIT的OS课程的时候发现自己动不动就因为只是的缺少而卡住，而这个学习占据了我工作之余很多的时间。1应该代表的是用户命令，2则是系统调用，3是库函数，4是设备，5是文件格式，6暂时看着没有，7是概览、约定以及其他，8是超级用户以及系统管理员命令。2. FILE数据类型是一个_iobuf的结构体封装成的，里面的具体成员信息在此也不做具体的了解了。根据上面的知识，应该可以推断出来，其实上面的fileno(stdin)的结果应该是0。
2023-03-10 22:03:01
527
原创 1634_linux中把pdf拆分成独立的图片文件
最近工作学习之中使用pdf的频次非常高，这种格式的通用性的确是不错。不过，有时候我希望通过图片的方式来插入一个pdf的页面到我的新文档中，这时候的各种截图等工具就显得不是很方便。采用-f –l的参数扩展，第一个参数代表first，第二个是last，后面跟一个数字就可以指定提取的页面。做了简单的体验之后感觉这个工具的确是非常小巧好用，从安装体积来看也是非常小巧，很适合部署到树莓派等简单的小服务器上去跑跑脚本之类的。整体的参数很类似我们熟悉的网络打印机的参数选择。当然，这个图形格式还是可以选择其他的格式的。
2023-03-04 10:13:09
284
原创 1633_xv6 book PC硬件与BootLoader
后面看了一下，其实也是有一定的考虑的。5. 这里介绍了xv6的BootLoader其实是进行了寄存器的初始化的，这部分内容之前看代码的时候其实是注意到过的。2. 经过之前对线性地址等概念的了解，顺带对全局描述表以及局部描述表等有了一定的了解，这里的内容看着顺利了很多。1. 处理器发展进化的过程中，分页模式这样的功能是从286开始出现的，而这时候的段寄存器的使用也变得复杂了。这里算是复习一下吧！2. 关于描述表的加载生效，这部分的描述感觉跟前面刚刚看到的线性地址资料中的段寄存器缓存寄存器的行为一致。
2023-02-26 18:58:10
227
原创 1632_x86中几种地址概念的理解
其实，几个概念中，最让我不理解的是线性地址，因为这个地址在不同的条件下可能代表不同的含义。而线性地址在使用分页功能的时候则会作为分页器的输入，经过分页器转换成物理地址。而权限，则是设置了权限的几级访问。3. 段缓存器从描述上看是具备一定的加速效果的，主要是在段寄存器的内容不发生变化的时候可以省略从内存中读取段描述表的过程。2. 在x86体系中，有两个地址相关的转换概念需要先明确一下，一个是分段，另一个是分页。2. 段选处理的过程是为了找出段描述符，关于段描述符的则是为了定义访问信息以及限制字段而设计的。
2023-02-26 18:56:59
327
原创 1631_MIT 6.828 lab1 HW的部分尝试与总结
这里到了函数调用后面，堆栈已经处理完了，因此单纯的软件操作暂时没有改掉堆栈存储的信息。这里应该也是由于这一部分的指令运行刚好没有局部量的操作，不然我们应该也能够看到一些堆栈信息的变化。这部分信息的查看比较底层，我个人觉得的确也是有一些无趣的，而且特别费脑筋，有种看不进去的感觉。此时的堆栈还是没有实际工作的，考虑向下增长的特性，ebp不应该为0，因此应该是没有实际工作。当运行到了这里，从堆栈的ebp以及esp来看，堆栈已经生效了。这个操作我按照上面的模式来查了一下，找到的是相同的地址。
2023-02-20 20:56:27
177
原创 1630_GNU的二进制分析工具nm简单使用探索
它的功能主要是显示出一个指定文件的符号信息的，而这个指定的文件可以是目标文件、可执行文件或者目标文件库文件。当然，IBM的这个nm并不是我这次要看得GNU的工具的nm，但是两者的功能类似。这个是使用nm分析目标文件的一个测试，这里面的信息分了三列，分别是地址信息、类型、名字。这里可以看得出来，其实这个地址信息的默认显示形式是十六进制，这个跟IBM的工具也是不同的。中间的类型，U代表符号未定义，T代表的是代码段，C代表的是未初始化的common数据。在GNU的工具中，大写的通常是代表全局而小写的则代表局部。
2023-02-11 19:26:32
525
原创 1629_MIT_6.828_xv6_chapter1操作系统的组织
宏内核的系统，在内核中实现了所有操作系统的功能。操作系统提供的进程隔离主要是通过了独立的进程堆栈空间以及存储映射技术来实现的，自然，堆栈空间其实还是可以继续细分为两种的。1. 操作系统的主要功能在上一个章节中其实是已经总结出来了，这里算是再次说明：硬件的抽象以及复用、进程之间的隔离、进程之间的交互。2. 隔离设计的实现其实是需要依赖于硬件功能的，这里依赖的硬件功能主要是存储映射，实现虚拟地址与物理地址之间的映射转换。2. 这部分的内容涉及到了太多的其他章节的知识，读的时候也有点迷糊，后面不行再回读一下。
2023-02-11 19:24:13
555
原创 1628_MIT 6.828 xv6_chapter0操作系统接口
在不会用管道的时候，我经常用临时文件的方式来实现类似的功能。4，在阻塞设计上更有优势。而wait返回当前进程退出子进程的PID，如果当前进程的子进程没有退出的那么wait会等待到有退出的之后返回退出子进程的PID。3. 中间简单说明了一下cat功能的实现，这里借用了1个巧妙的约定，那就是0、1、2三个文件描述符的作用是特殊的，并且在进程之间也是可以遵循相同标准的。1. 这里给出来了一组OS的常用接口，其实这些类似的功能在学习perl或者python脚本语言的时候就接触过一些类似的功能，也有一个类似的组合。
2023-02-11 19:22:46
348
原创 1627_MIT 6.828 PC硬件与x86编程幻灯片资料阅读
其实，为了解决之前的疑惑相关的内容我已经从其他的资料中看到了类似的内容，这次简单做一个快速的勾勒性阅读。这个图中表达的内容跟我之前看过的一份网络上的文章是一致的，这在之前的笔记中能够找到。这一页讲的其实是QEMU的模拟实现，但是这里的256M可能恰好是跟之前看到的JOS所能够访问的存储空间一致，让我觉得有点巧妙的关联感。这里提到的向前兼容的特性在我之前分析的UNIX类型的JOS系统中看到过，JOS的BootLoader设计就是按照这样的一个流程。有了前面的调用约定模型，理解这样的对等汇编其实还是很容易的。
2023-02-11 19:19:36
537
原创 1626_MIT 6.828 lab1课程大纲学习过程整理
最终，我的编译在修改了文件之后通过了，可是运行的时候异常。遇到的这个问题差点让我放弃这个课程，还好最终切换了一个方式，直接换了32bit的系统，结果一切顺利。其中，这个图解的git工作过程我觉得还是很不错的，简短但是很奏效，能够快速了解git进行版本管理的一些基本理念。2. 要想顺利完成stack的监控，按照试验数据自己总结规律是可以的，更好的方式其实是去看一下函数调用call stack的约定设计说明。上面的标注还是堆栈处理相关的部分，下面的这个标注主要是描述了stabs信息如何传递到程序的。
2023-02-11 19:18:05
543
原创 1625_MIT 6.828 stabs文档信息整理_下
其他的编译器可能没有提供这个好用的工具，GNU的工具中是带的。这一页描述了参数传递往寄存器传递的情况，其实这个在我现在接触的x86的平台上是没有的。但是，通过之前看过的资料可以知道其实现在比较流行的RISC-V其实是采用了这样的模式。这里是关于数组的stabs信息生成，例子中的数组其实有3个元素，但是生成的信息由编译器加工后进行了4字节对齐，因此在实际的场景中占用了4个字节的信息。关于结构体的部分，通过计算可以看得出来后面的数值其实是代表了空间的占用量。其中，有一个-20指出来了在堆栈中的偏移量。
2023-02-11 19:14:13
618
原创 1624_MIT 6.828 stabs文档信息整理_上
暂且整理这么多，我跳过了整个C++的篇章以及附录，因此后面的部分应该可以再来一份笔记整理完。后面的文档中，类似的信息我也跳过了一大部分。1. 这一页最开始的地方其实是我学习这个课程最需要找的部分，也就是GCC工具链生成的结果文件中行号存储在什么地方。2. 静态量中，s代表其作用于是文件范围的，而v代表其作用是函数范围的。1. 程序的编码结构主要包括主函数名称、源文件、包含的文件名称、行号、进程名、类型以及代码的开始与结尾。在C语言中其实是有一个明确的概念的，那就是返回值是void的函数用来设计进程。
2023-02-10 22:10:31
451
原创 1623_MIT 6.828 在JOS中增加一条交互命令
看得出来，help已经出现了增加的命令backtrace信息。看起来，这个交互命令已经实现了，非常简单。接下来，分析一下一个交互命令的调用过程。从这里找到了一个配置信息，简单看了一下格式判断基本就是这里。在此基础上，先尝试增加了上面代码中的一行配置。这两个命令分别是help以及kerninfo，具体的交互效果如上。这样，就有一定的参考范本可以去尝试实施了。在lab1中有一个实现要求是要做一个交互式的命令添加，增加一个backtrace。在做这个之前，其实JOS已经提供了2个类似的交互式命令。
2023-02-10 22:08:02
20
原创 1622_MIT 6.828 lab1中mon_backtrace的实现与分析
这里是要求实现的部分，但是需要注意：如果按照注释的说明直接赋值为一个右边的索引值，这个数值是错误的。首先，这个函数对传入的eip信息进行初始化，接着从链接器提供的符号信息之中获取stabs的相关信息并进行有效性的检查。文件解析的部分则要比这个复杂很多，但是好的消息是其实用来实验的lab1的JOS系统中已经实现了这样的一个功能，只是欠缺一点信息的处理。这是修改之后调试过程中的一次记录，此时，代码中的行号还是按照注释中的提示实现的。而这次是按照文档中的内容修改之后的效果，已经实现了期待的效果。
2023-02-10 22:04:57
401
原创 1621_MIT 6.828 lab1中从BootLoader到kernel启动的大概过程分析
结合这个存储分布的图示可以知道，这个地址是Low Memory中的一个地址信息，属于内存部分。其实这个过程在前面的笔记梳理过程中基本上已经打过照面了，但是这个过程中的一些起承转合的过程没有完全串起来。这里是通过call指令直接调用了一个地址的信息，而这个地址信息其实是之前从ELF文件中读取出来的。继续下去，在这个C代码中先是读取了磁盘信息，接着根据读取的C盘信息调用了一个函数，正式进入到了kernel。这样，整个启动过程的大概环节以及中间的一些依赖以及约束，还有用到的简单工具基本也就梳理出来一个框架了。
2023-02-07 21:27:17
340
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人