ucore-project4: interrupt -- 内嵌汇编在-Os优化时出错分析

为了打印数字，将printf添加进去，结果打印出来乱码，并且是原来正确的、没有用printf打印出来的代码也变成了乱码。

 

使用readelf -e查看编译出来的kernel文件（kernel.out），发现代码是正确的，打印代码引用的打印字符串的地址处的确放着正确的打印字符串。

 

需要看到加载到内存后是什么样子，看来应该是读取内核到内存中出错了。不过以前读取内核没有问题啊？查看了以前读取的内核不到一个扇区，而现在内核代码有三个扇区那么大。重新看了一遍bootc.c代码，没有发现问题。

 

没有调试器真不方便啊，以前记得调试不了，加不了断点。对了，加不了断点是因为找不到symbol，img文件中没有说明symbol文件的位置，而img文件又不是一个合法的elf文件，gdb没法从img文件里拿到symbol信息（包括调试信息）。

 

好办，在进入gdb后，先执行symbol-file boot/boot.tmp将启动扇区代码的符号信息加载进来，再执行add-symbol-file kernel/kernel.out 0x100000将内核代码的符号信息加载进来。

 

之后target remote :1234， b start32asm， b main32c，b kstart，哈哈，加载没问题。

 

但是调试bootc.c的代码时出问题了，编译bootc.c时加了-Os选项，结果很多函数、局部变量为减小空间给优化没了，打印局部变量出来的是错误信息。而去掉-Os后，启动代码变为764字节，超出一个扇区大小。把输出的代码全干掉，还超，把启用A20代码简化，还超，最后把等待硬盘就绪的指令干掉（反正调试时时间足够），才把大小压缩到500字节。

 

ok，开始调试，呃，没有任何问题，一切正常。。。。

 

加上-Os，出错，去掉-Os，正常。。。gcc的优化会出错！！！！

 

gcc的优化都不能相信，还有什么是可以信任的呢？经过几个小时不断地调试和对比，最终找到了原因：

gcc优化绝大多数情况下是正确的，除非你使用了内嵌汇编，并且没有正确告诉gcc内嵌汇编中的汇编代码是怎么影响寄存器的。

 

出错地方的代码是这样的：

static void readsect(void *va, int sectno)
{
    waitdisk();
    outb(1, xxx);
    outb(xx,xx);
    outb(xx,xx);
    outb(xx,xx);
    outb(xx,xx);

    waitdisk();
    insl(va, len, port);
}

static void readsegment(void *va, int size, int offset)
{
    ....
    for (i=beginsect; i<=endsect; i++, va+=SECTSIZE)
    {
        readsect(va, i);
    }
}

 

没有优化的时候没有任何问题，所有调用都是正常的。加上-Os优化后，readsect函数被优化掉了，内容直接放到readsegment的for循环中。很多局部变量都被优化掉，放在内部寄存器中。其中i被放到了ebx，而va被放到了edi：

 

mov $0x1f0, %edx
mov $0x80, %ecx
cld
rep insl (%dx), %es:(%edi)
inc %ebx
add $0x200, %edi
cmp -0x10(%ebp), %ebx
jbe 7c5e
pop %eax
....

 看起来没什么问题。不过执行起来就完蛋了：

 rep insl指令在执行过程中会增加edi的值，而后面仍然有一条add $0x200,%edi语句给edi加值，结果造成了拷贝扇区时，第一个扇区拷贝到0x100000~0x100200地址处，第二个扇区拷贝到0x100400~0x100600处，中间0x100200~0x100400空间被忽略过去了！

 

gcc为什么会这么傻？犯这种基本错误？难道优化就这么脆弱吗？慢着，ucore自己的代码没有问题啊，忽然想起来，insl是在C代码中的嵌入汇编语句，而这条指令在写的时候图简单，与ucore的相比少了很多东西（当时还为自己写的代码比ucore的简洁很多而偷偷得意来着）：

static inline void insl(void *va, int size, int port)
{
    asm("rep insl"::"D"(va),"c"(size),"d"(port));
}

 

static inline void insl(void *va, uint32_t size, uint32_t port)
{
    asm("rep;insl"
           : "=D"(va), "=c"(size)
           : "d"(port), "0"(va), "1"(size)
           : "memory", "cc");
}

 

用ucore的代码加了-Os优化后出来的代码如下：

mov %esi, %edi
mov $0x1f0, %edx
mov $0x80, %ecx
cld
rep insl (%dx), %es:(%edi)
inc %ebx
add $0x200, %esi
cmp -0x10(%ebp), %ebx
jbe 7c5e
pop %eax
....

 

可以看出，ucore生成的代码中，因为指示了edi会变(=D)，从而使用esi，而不是edi来存放va，此时就没有任何问题了。对我的insl做如下修改：

static inline void insl(void *va, int size, int port)
{
    asm("rep insl":"=D"(va),"=c"(size):"0"(va),"1"(size),"d"(port));
}

 

重新编译，这次可以成功运行了。

 

之后就好办了，printf打印出backspace通过串口传过去的值是127，而ctrl+H的值是8，ctrl+H可以实现退格，当程序收到127或8时，顺序打印8, 空格, 8三个字符，就可以完美实现backspace的效果。

 

总结一下：

1. gcc的优化逻辑基本不怎么认识嵌入汇编，所以嵌入汇编中一定要详细说明自己的输入输出，分别影响了什么，将这些信息告诉gcc后，gcc在优化时才能更好地与嵌入汇编进行配合。

 

2. 这个问题一直存在，不过最初内核大小不到一个扇区，不会有问题，而添加printf后，增加到4个扇区，该问题就暴露出来了

 

3. ld在连接内核时，使用的顺序是kernel/driver/console.o, kernel/start/start.o, kernel/printf/printf.o，其中新添加的printf代码在最后面，按理说即使printf有问题，也不应该影响到前面的代码。但要知道，程序编译后代码在一个section(.text)，字符串常量在另一个section(.rodata), 连接时同名段会放在一起。这样，三个.o文件的.text合成一个大的.text section，而他们的.rodata合成一个大的.rodata section，放在.text后面。从而start.o代码中使用了.rodata中的字符串常量，仍然会受到影响。

 

4. 这次定位仍然严重依赖调试器，虽然搞明白了怎么用gdb调试qemu中的内核，但对自己发现问题的能力没有任何帮助。说白了，使用调试器就不动脑子了，只一步步看代码怎么执行，执行到哪里数据会变成什么样子，变成这个样子后好像不太对。。。这种分析方式实际上效率很低，并且对自己的能力没有任何提高。以前很多人说的很对：“要减少对调试器的使用”。多看代码，多静态分析代码，在脑子里模拟cpu执行汇编指令，时刻敏锐地分析代码执行会有什么问题。多做这种练习，锻炼自己的思维能力，对自己的程序写作、分析能力以及问题定位能力会有很大提升。并且也可以锻炼克服困难、踏踏实实的品质。