在编译内核时有人遇到下面这个问题：

kernel/built-in.o: In function `getnstimeofday':
(.text+0xb6ae): undefined reference to `__umoddi3'
kernel/built-in.o: In function `getnstimeofday':
(.text+0xb6ce): undefined reference to `__udivdi3'

这个问题可以在用户空间重现，不过不是很容易，我实验了一下，在i386上，并不是所有的64位整数操作都会被转化成调用__umoddi3，gcc bugzilla上有演示程序，如下：

[c]

define NSEC_PER_SEC 1000000000UL

int rmg(void);

int main(void)
{
/ int sec; /
return rmg();
}

int rmg(void)
{
static unsigned long long nsec = 0;
static int sec = 0;
while (sec = NSEC_PER_SEC, 0)) {
nsec -= NSEC_PER_SEC;
++sec;
}
}
return sec;
}
[/c]

这样编译它：% gcc -nostdlib -O2 -o umoddi3 umoddi3.c，就会得到：

/tmp/ccycM684.o: In function `rmg':
umoddi3.c:(.text+0x87): undefined reference to `__udivdi3'
collect2: ld returned 1 exit status

问题重现了。这里的问题是，对于nsec来说，内层的循环其实等价于求模运算，gcc在优化时发现了这一点，而且硬件本身也不支持对64位整数直接进行算术运算，所以gcc会把这一步优化成调用内部函数udivdi3()和umoddi3()，这两个函数在libgcc中（见gcc源代码gcc/libgcc2.c），libgcc默认和libc一样是要被加载的，但如果我们加了-nostdlib（Linux内核是更好的例子），这个问题就会出现了。

知道原因了，怎么解决？网上有两种方法，一种是像这个补丁那样，在循环中插入下面这条内联汇编：

asm(“” : “+r”(ns));

这句是告诉gcc把ns这个变量放到寄存器中，并且既有读操作也有写操作，所以后面再用它时必须重新读取，这样就消除了上面的优化。

另一种解决方法是添加新的编译选项：-fno-tree-scev-cprop，这个选项似乎没有文档，至少我没找到。说说它的大体意思。scev应该是SCalar EVolutions，什么意思不知道。:( cprop应该是Copy PROPagation，这个应该很容易理解，就是赋值的传播，比如：

i = 10;
a = i;
b = i;

其实就是：

a = 10;
b = 10;

可见，编译优化是门大学问，写个编译器丝毫不比写个内核容易。:-P