Linux 内核拥有多种调试工具。其中之一是内核函数追踪器，它会追踪函数调用，查找错误的内存分配和其他问题。

来自 Intel 的 Changbin Du 最近发布了一些代码，通过增加实际编译到内核中的函数调用数量来增加函数追踪器的范围。并非所有函数调用都会被实际编译——有些会被“内联”，这是一种 C 语言特性，允许将函数代码复制到调用它的位置，从而使其运行速度更快。缺点是编译后的二进制文件会因需要存储的该函数副本数量而增大。

但是，并非所有内联函数都是开发者明确想要的。 GNU C 编译器 (GCC) 也会使用自己的算法来决定内联各种函数。每当它在 Linux 内核中这样做时，函数追踪器就无法追踪。

Changbin 的代码仍然允许函数被内联，但前提是它们明确使用了 C 语言的 inline 关键字。所有其他由 GCC 本身完成的内联都会被阻止。 这会产生效率较低的代码，因此 Changbin 的代码永远不会在生产内核构建中使用。但另一方面，它会产生可以被函数追踪器更彻底检查的代码，因此 Changbin 的代码对于内核开发人员来说非常有用。

在他发布补丁后，错误报告像雨后春笋般涌现在内核中，这些错误报告都来自 GCC 一直在默默内联的函数。 因此，绝对没有人反对这个特定的补丁。

然而，函数追踪器产生了一些奇怪的误报，声称它发现了实际上不存在的错误。 这让一些内核开发人员略微停顿了一下，他们简短地讨论了如何消除这些误报，直到他们意识到这真的无关紧要。 他们认为，误报可能表明 GCC 存在问题，因此 GCC 的人应该能够看到这些误报，而不是将它们隐藏在解决方法后面。

那个特殊的问题——什么是内核问题，什么是 GCC 问题——具有潜在的爆炸性。 这次没有导致任何结果，但在过去，它曾导致内核人员和 GCC 人员之间激烈的战争。 其中一场战争是关于 GCC 未能支持 Pentium 处理器，并导致一群开发人员将 GCC 开发分叉到一个竞争项目，称为 egcs。 该分叉非常成功，并开始在主流 Linux 发行版中使用，而不是 GCC。 最终，只有在 egcs 代码合并到 GCC 主分支后，并且未来的 GCC 开发在 1999 年移交给 egcs 开发团队后，两个分支之间的冲突才得到解决。

注意：如果您在上面被提及并且想在评论部分上方发布回复，请将带有您的回复文本的消息发送至 ljeditor@linuxjournal.com。