ucore-project2: loadkernel(1)

本工程很简单，就是在启动完成后，从第一个硬盘的第二个分区开始，加载8个分区到内存0x10000处。

 

本工程总是运行出错，C代码进不去，出现和proj1那样16进制代码重复运行的问题。第一反应就是跳转到32位时出错了，看了很多遍代码，没有问题，仔细对比了proj1和proj2的代码，尤其是启动部分代码，也没有问题。proj2和proj1唯一变化的就是在后面加了读硬盘的代码，会不会这些代码有错误？但是这些代码前面加了打印，为什么也没有打印出来？难道这些代码出错，导致前面执行打印的代码执行完了，还没来得及出效果就重启了？（后来事实证明串口打印没有出现这种情况，只要往串口输出，就会打印）。

 

把新代码注释掉，仍然有问题。甚至把整个C代码全部注释掉，还是有问题。这时开始烦躁了，代码一模一样，为什么会有问题呢？这时应该有发散型思维，不要总是扣着代码这一块儿来考虑，应该想想最后执行的是二进制代码，要端到端考虑一下二进制代码的生成、执行过程哪个地方是薄弱环节，从最可能有问题的方面入手进行考察。

 

代码生成过程如下：

1. 写源代码

2. 编译

3. 签名（55aa）

4. 放到img

 

代码执行过程：

5. 通过qemu执行img

 

其中写源代码部分检查和proj1一样，此时不要烦躁，要看看其他部分。此时第一直觉是怀疑第5步，但第5步是无法验证的，因为对qemu实际上不了解，此时认为其他地方不可能有问题，又怀疑qemu，结果开始烦躁。实际上第2、3、4步都应该检查一下。而qemu已经用了这么多年，第5步应该认为不是薄弱环节，最后再怀疑它。2、3、4是编译过程，一点都没改，在proj1没问题，在proj2应该也没问题，所以认为不会有问题。实际上源代码改了，2、3、4虽然过程没问题，但输出都可能有问题。

 

本次发现问题的过程还是不相信qemu，于是再次执行proj1，发现没问题。重新执行proj2，发现有问题。因为对比了两次的执行，万幸dd会打印出一些输出，发现proj1中dd的启动扇区512字节，而proj2中扇区是684字节。从而发现了问题。说明代码写的太多了，启动扇区太大了。签名把启动扇区破坏了。

 

后续调试建议：

1. 全面考虑影响出问题的原因

2. 分析哪些不容易出问题

3. 先考虑容易出问题的部分。

 

对于ucore，容易出问题的部分，按照顺序排序，分别是源代码，编译过程，最后才是执行，而执行虽然是最不可能出问题的，如果已经考虑了所有其他部分的影响，还是没有发现原因，应该就是qemu出了问题。除非自己没有考虑周全。