GCC

简化现代 GCC 的函数追踪

Steven Rostedt 想要做一些整理工作,特别是关于调试内核时使用的函数追踪代码。 到那时为止,内核可以使用 GCC 的 -pg 标志或者 -pg 和 -mfentry 的组合来启用函数追踪。 在每种情况下,GCC 都会创建一个特殊的例程,该例程会在每个函数开始时执行,因此内核可以跟踪对所有函数的调用。

疯狂的编译器优化

内核开发总是很奇怪。 Andrea Parri 最近发布了一个补丁,用于更改多线程操作期间内存读取的顺序,这样如果一个读取依赖于下一个读取,则第二个读取实际上不能在第一个读取之前发生。 这样做的问题是,该错误实际上永远不会发生,并且该修复使内核的行为对于开发人员来说不太直观。 特别是 Peter Zijlstra 投了反对票,称不可能构建一个能够触发相关错误的物理系统。

将编译器依赖性检查移至 Kconfig

Linux 内核配置系统 Kconfig 使用的宏语言与 make 构建工具的宏语言非常相似。 但是,有一些差异。 当然,make 被设计为通用构建工具,而 Kconfig 是 Linux 内核特有的。 但是,为什么内核开发人员会创建一个与现有通用工具如此相似的全新宏语言呢?

最低 GCC 版本可能从 3.2 跳到 4.8

关于支持构建 Linux 内核的最早 GCC 编译器版本的问题会定期出现。 理想的情况是 Linux 可以在所有 GCC 版本下编译,因为你永远不知道有人正在运行什么样的系统。 也许他们公司的安全团队必须批准其高度敏感设备的所有软件升级,而 GCC 在该列表中排名较低。 也许他们需要节省尽可能多的空间,而最新版本的 GCC 太大了。 有各种各样的原因导致有人可能被旧软件困住。