^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) ORC unwinder
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) ========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) The kernel CONFIG_UNWINDER_ORC option enables the ORC unwinder, which is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) similar in concept to a DWARF unwinder. The difference is that the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) format of the ORC data is much simpler than DWARF, which in turn allows
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) the ORC unwinder to be much simpler and faster.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) The ORC data consists of unwind tables which are generated by objtool.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) They contain out-of-band data which is used by the in-kernel ORC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) unwinder. Objtool generates the ORC data by first doing compile-time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) stack metadata validation (CONFIG_STACK_VALIDATION). After analyzing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) all the code paths of a .o file, it determines information about the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) stack state at each instruction address in the file and outputs that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) information to the .orc_unwind and .orc_unwind_ip sections.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) The per-object ORC sections are combined at link time and are sorted and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) post-processed at boot time. The unwinder uses the resulting data to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) correlate instruction addresses with their stack states at run time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) ORC vs frame pointers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) With frame pointers enabled, GCC adds instrumentation code to every
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) function in the kernel. The kernel's .text size increases by about
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) 3.2%, resulting in a broad kernel-wide slowdown. Measurements by Mel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) Gorman [1]_ have shown a slowdown of 5-10% for some workloads.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) In contrast, the ORC unwinder has no effect on text size or runtime
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) performance, because the debuginfo is out of band. So if you disable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) frame pointers and enable the ORC unwinder, you get a nice performance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) improvement across the board, and still have reliable stack traces.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) Ingo Molnar says:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) "Note that it's not just a performance improvement, but also an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) instruction cache locality improvement: 3.2% .text savings almost
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) directly transform into a similarly sized reduction in cache
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) footprint. That can transform to even higher speedups for workloads
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) whose cache locality is borderline."
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) Another benefit of ORC compared to frame pointers is that it can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) reliably unwind across interrupts and exceptions. Frame pointer based
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) unwinds can sometimes skip the caller of the interrupted function, if it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) was a leaf function or if the interrupt hit before the frame pointer was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) saved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) The main disadvantage of the ORC unwinder compared to frame pointers is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) that it needs more memory to store the ORC unwind tables: roughly 2-4MB
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) depending on the kernel config.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) ORC vs DWARF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) ORC debuginfo's advantage over DWARF itself is that it's much simpler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) It gets rid of the complex DWARF CFI state machine and also gets rid of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) the tracking of unnecessary registers. This allows the unwinder to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) much simpler, meaning fewer bugs, which is especially important for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) mission critical oops code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) The simpler debuginfo format also enables the unwinder to be much faster
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) than DWARF, which is important for perf and lockdep. In a basic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) performance test by Jiri Slaby [2]_, the ORC unwinder was about 20x
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) faster than an out-of-tree DWARF unwinder. (Note: That measurement was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) taken before some performance tweaks were added, which doubled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) performance, so the speedup over DWARF may be closer to 40x.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) The ORC data format does have a few downsides compared to DWARF. ORC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) unwind tables take up ~50% more RAM (+1.3MB on an x86 defconfig kernel)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) than DWARF-based eh_frame tables.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) Another potential downside is that, as GCC evolves, it's conceivable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) that the ORC data may end up being *too* simple to describe the state of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) the stack for certain optimizations. But IMO this is unlikely because
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) GCC saves the frame pointer for any unusual stack adjustments it does,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) so I suspect we'll really only ever need to keep track of the stack
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) pointer and the frame pointer between call frames. But even if we do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) end up having to track all the registers DWARF tracks, at least we will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) still be able to control the format, e.g. no complex state machines.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) ORC unwind table generation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) The ORC data is generated by objtool. With the existing compile-time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) stack metadata validation feature, objtool already follows all code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) paths, and so it already has all the information it needs to be able to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) generate ORC data from scratch. So it's an easy step to go from stack
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) validation to ORC data generation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) It should be possible to instead generate the ORC data with a simple
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) tool which converts DWARF to ORC data. However, such a solution would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) be incomplete due to the kernel's extensive use of asm, inline asm, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) special sections like exception tables.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) That could be rectified by manually annotating those special code paths
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) using GNU assembler .cfi annotations in .S files, and homegrown
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) annotations for inline asm in .c files. But asm annotations were tried
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) in the past and were found to be unmaintainable. They were often
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) incorrect/incomplete and made the code harder to read and keep updated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) And based on looking at glibc code, annotating inline asm in .c files
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) might be even worse.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) Objtool still needs a few annotations, but only in code which does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) unusual things to the stack like entry code. And even then, far fewer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) annotations are needed than what DWARF would need, so they're much more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) maintainable than DWARF CFI annotations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) So the advantages of using objtool to generate ORC data are that it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) gives more accurate debuginfo, with very few annotations. It also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) insulates the kernel from toolchain bugs which can be very painful to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) deal with in the kernel since we often have to workaround issues in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) older versions of the toolchain for years.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) The downside is that the unwinder now becomes dependent on objtool's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) ability to reverse engineer GCC code flow. If GCC optimizations become
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) too complicated for objtool to follow, the ORC data generation might
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) stop working or become incomplete. (It's worth noting that livepatch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) already has such a dependency on objtool's ability to follow GCC code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) flow.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) If newer versions of GCC come up with some optimizations which break
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) objtool, we may need to revisit the current implementation. Some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) possible solutions would be asking GCC to make the optimizations more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) palatable, or having objtool use DWARF as an additional input, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) creating a GCC plugin to assist objtool with its analysis. But for now,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) objtool follows GCC code quite well.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) Unwinder implementation details
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) Objtool generates the ORC data by integrating with the compile-time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) stack metadata validation feature, which is described in detail in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) tools/objtool/Documentation/stack-validation.txt. After analyzing all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) the code paths of a .o file, it creates an array of orc_entry structs,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) and a parallel array of instruction addresses associated with those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) structs, and writes them to the .orc_unwind and .orc_unwind_ip sections
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) respectively.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) The ORC data is split into the two arrays for performance reasons, to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) make the searchable part of the data (.orc_unwind_ip) more compact. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) arrays are sorted in parallel at boot time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) Performance is further improved by the use of a fast lookup table which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) is created at runtime. The fast lookup table associates a given address
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) with a range of indices for the .orc_unwind table, so that only a small
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) subset of the table needs to be searched.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) Etymology
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) =========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) enemies. Similarly, the ORC unwinder was created in opposition to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) complexity and slowness of DWARF.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) "Although Orcs rarely consider multiple solutions to a problem, they do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) excel at getting things done because they are creatures of action, not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) thought." [3]_ Similarly, unlike the esoteric DWARF unwinder, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) veracious ORC unwinder wastes no time or siloconic effort decoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) variable-length zero-extended unsigned-integer byte-coded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) state-machine-based debug information entries.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) Similar to how Orcs frequently unravel the well-intentioned plans of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) their adversaries, the ORC unwinder frequently unravels stacks with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) brutal, unyielding efficiency.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) ORC stands for Oops Rewind Capability.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) .. [1] https://lkml.kernel.org/r/20170602104048.jkkzssljsompjdwy@suse.de
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) .. [2] https://lkml.kernel.org/r/d2ca5435-6386-29b8-db87-7f227c2b713a@suse.cz
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) .. [3] http://dustin.wikidot.com/half-orcs-and-orcs
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags