标签：GCC DWARF objtool unwinder ORC 内核 堆栈 txt orc
翻译内核文档重点部分，难免有误，请见谅
内核版本4.19.190
内核 CONFIG_UNWINDER_ORC 选项启用 ORC 展开器，它在概念上类似于 DWARF 展开器。 不同的是，ORC 数据的格式比 DWARF 简单得多，这反过来又使 ORC unwinder 更简单、更快。
ORC 数据由 objtool 生成的展开表组成.它们包含内核内 ORC 使用的带外数据开卷机, Objtool 生成ORC 数据通过首次编译时的（stack metadata validation） (CONFIG_STACK_VALIDATION)。之后分析
所有代码路径的.o 文件。，它确定有关文件中每个指令地址的堆栈状态信息并输出这些信息到.orc_unwind 和 .orc_unwind_ip 段。
每个对象的 ORC 部分在链接时合并，并在引导时进行排序和后续处理。展开器在运行时使用结果数据将指令地址与其堆栈状态相关联
ORC vs frame pointers
---------------------
启用帧指针后，GCC 将检测代码添加到每个内核中的函数。 内核的 .text 大小增加了大约
3.2%，会导致内核范围的广泛变缓。 Mel Gorman [1] 的测量表明，某些工作负载的速度降低了 5-10%。
相比之下，ORC unwinder 对文本大小或运行时间没有影响性能，因为 debuginfo 是带外的。所以如果你禁用帧指针并启用 ORC 展开器，您可以获得全面的性能改进，并且仍然具有可靠的堆栈跟踪。
Ingo Molnar 说：
“请注意，这不仅是性能改进，也是指令缓存局部性改进：3.2% .text 节省几乎直接转换成类似大小的减少缓存脚印。 这可以使其缓存位置处于临界状态的工作负载转化为更高速率。
与帧指针相比，ORC 的另一个好处是它可以跨中断和异常可靠地展开。基于帧指针unwinds 有时可以跳过被中断函数的调用者，如果它是叶函数，或者如果在帧指针之前中断命中保存。
与帧指针相比，ORC 展开器的主要缺点是它需要更多内存来存储 ORC 展开表：大约 2-4MB取决于内核配置。
ORC vs DWARF
------------
ORC debuginfo 相对于 DWARF 本身的优势在于它更简单。它摆脱了复杂的 DWARF CFI 状态机，也摆脱了跟踪不必要的寄存器。这允许开卷机更简单，意味着更少的错误，这对于
关键任务 oops 代码是非常重要的。
更简单的 debuginfo 格式也使展开器比 DWARF更快，这对于 perf 和 lockdep 很重要，一个基本由 Jiri Slaby [2] 进行的性能测试，ORC 开卷机大约
比树外 DWARF 展开器快20 倍（注：那个测量是在添加一些性能调整之前做的，这翻了一番性能，因此比DWARF 的速率提高可能接近 40 倍。）
与 DWARF 相比，ORC 数据格式确实有一些缺点。 ORC 展开表比基于 DWARF 的 eh_frame 表占用的 RAM 多约 50%（在 x86 defconfig 内核上为 +1.3MB）。
另一个潜在的缺点是，随着 GCC 的发展，这是可以想象的，ORC 数据可能最终会变得*太*简单地描述堆栈的状态为了特定的优化。但是 IMO 这不太可能，因为 GCC 会为任何不寻常的堆栈调整保存帧指针
所以我怀疑我们真的只需要跟踪调用帧之间的堆栈指针和帧指针，但即使我们最终不得不跟踪 DWARF 跟踪的所有寄存器，至少我们仍然能够控制格式，例如 没有复杂的状态机。
ORC unwind table generation
---------------------------
ORC 数据由 objtool 生成。 使用现有的编译时堆栈元数据验证功能，objtool 已经跟随了所有代码路径，因此它已经拥有生成 ORC 数据所需的所有信息。 因此，从堆栈验证到 ORC 数据生成是一个简单的步骤。
应该可以用一个简单将DWARF换为ORC数据的工具的方法来代替生成 ORC 数据，由于内核广泛使用 asm、内联 asm 以及异常表等特殊部分，这样的解决方案将是不完整的
这可以通过手动注释那些特殊的代码路径来纠正在 .S 文件中使用 GNU 汇编器的 .cfi 注释，并自行开发.c 文件中的内联 asm 注释。 但是尝试了asm注释在过去并且被发现是不可维护的。 他们经常
不正确/不完整，使代码更难阅读和保持更新。并基于查看 glibc 代码，在 .c 文件中注释内联 asm 可能更糟。
Objtool 仍然需要一些注释，但只是代码中对于堆栈来说不寻常的东西，例如入口代码。 即便如此，需要的注释比 DWARF 需要的少得多，所以它们要比 DWARF CFI 注释更易于维护。
所以使用 objtool 生成 ORC 数据的好处是提供更准确的调试信息，注释很少。它也是将内核与可能要在内核中处理的非常痛苦的工具链错误隔离开来，因为我们经常需要解决多年的旧版本工具链问题。
缺点是展开器现在变得依赖于 objtool 对 GCC 代码流进行逆向工程的能力。如果 GCC 优化变得过于复杂以至于 objtool 无法遵循，ORC 数据生成可能会停止工作或变得不完整。
（值得注意的是，livepatch 已经对 objtool 遵循 GCC 代码流的能力有这样的依赖。）
如果较新版本的 GCC 提出了一些破坏 objtool 的优化，我们可能需要重新审视当前的实现。 一些可能的解决方案是要求 GCC 使优化更容易接受，或者让 objtool 使用 DWARF 作为附加输入，或者创建一个 GCC 插件来帮助 objtool 进行分析。 但就目前而言，objtool 很好地遵循了 GCC 代码。
Unwinder implementation details
-------------------------------
Objtool 通过编译时集成的堆栈元数据验证功能生成 ORC 数据。详细描述在工具/objtool/文档/stack-validation.txt。分析全部代码路径的
.o 文件后。它创建一个 orc_entry 结构数组，以及与这些结构关联的指令地址的并行数组，并将它们分别写入 .orc_unwind 和 .orc_unwind_ip 段。
出于性能原因，ORC 数据被分成两个数组，以使数据的可搜索部分 (.orc_unwind_ip) 更紧凑。 数组在引导时并行排序。
通过使用在运行时创建的快速查找表进一步提高了性能。 快速查找表将给定地址与 .orc_unwind 表的索引范围相关联，因此只需要搜索表的一小部分。
Etymology（词源）
---------
兽人，中世纪民间传说中的可怕生物，是矮人天生的敌人，同样的，ORC 开卷机的创建是为了反对DWARF 的复杂性和缓慢性。
“虽然兽人很少考虑一个问题的多种解决方案，但他们确实 擅长把事情做好，因为它们是行动的生物，而不是思想。” 同样，与深奥的 DWARF 展开器不同，真实的 ORC 展开器不浪费时间或 siloconic 去解码
基于状态机的可变长度零扩展无符号整数字节编码的调试信息条目。
类似于兽人经常解开他们的他们的对手的善意计划。ORC 开卷机经常用残酷，不屈不挠的效率来解开栈。
ORC 代表Oops的倒带能力。
[1] https://lkml.kernel.org/r/20170602104048.jkkzssljsompjdwy@suse.de
[2] https://lkml.kernel.org/r/d2ca5435-6386-29b8-db87-7f227c2b713a@suse.cz
[3] http://dustin.wikidot.com/half-orcs-and-orcs
标签：GCC,DWARF,objtool,unwinder,ORC,内核,堆栈,txt,orc 来源： https://www.cnblogs.com/lh03061238/p/16178142.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。