@@ -11,9 +11,6 @@ analyzes every .o file and ensures the validity of its stack metadata.
1111It enforces a set of rules on asm code and C inline assembly code so
1212that stack traces can be reliable.
1313
14- Currently it only checks frame pointer usage, but there are plans to add
15- CFI validation for C files and CFI generation for asm files.
16-
1714For each function, it recursively follows all possible code paths and
1815validates the correct frame pointer state at each instruction.
1916
@@ -23,6 +20,10 @@ alternative execution paths to a given instruction (or set of
2320instructions). Similarly, it knows how to follow switch statements, for
2421which gcc sometimes uses jump tables.
2522
23+ (Objtool also has an 'orc generate' subcommand which generates debuginfo
24+ for the ORC unwinder. See Documentation/x86/orc-unwinder.txt in the
25+ kernel tree for more details.)
26+
2627
2728Why do we need stack metadata validation?
2829-----------------------------------------
@@ -93,37 +94,14 @@ a) More reliable stack traces for frame pointer enabled kernels
9394 or at the very end of the function after the stack frame has been
9495 destroyed. This is an inherent limitation of frame pointers.
9596
96- b) 100% reliable stack traces for DWARF enabled kernels
97-
98- (NOTE: This is not yet implemented)
99-
100- As an alternative to frame pointers, DWARF Call Frame Information
101- (CFI) metadata can be used to walk the stack. Unlike frame pointers,
102- CFI metadata is out of band. So it doesn't affect runtime
103- performance and it can be reliable even when interrupts or exceptions
104- are involved.
105-
106- For C code, gcc automatically generates DWARF CFI metadata. But for
107- asm code, generating CFI is a tedious manual approach which requires
108- manually placed .cfi assembler macros to be scattered throughout the
109- code. It's clumsy and very easy to get wrong, and it makes the real
110- code harder to read.
111-
112- Stacktool will improve this situation in several ways. For code
113- which already has CFI annotations, it will validate them. For code
114- which doesn't have CFI annotations, it will generate them. So an
115- architecture can opt to strip out all the manual .cfi annotations
116- from their asm code and have objtool generate them instead.
97+ b) ORC (Oops Rewind Capability) unwind table generation
11798
118- We might also add a runtime stack validation debug option where we
119- periodically walk the stack from schedule() and/or an NMI to ensure
120- that the stack metadata is sane and that we reach the bottom of the
121- stack .
99+ An alternative to frame pointers and DWARF, ORC unwind data can be
100+ used to walk the stack. Unlike frame pointers, ORC data is out of
101+ band. So it doesn't affect runtime performance and it can be
102+ reliable even when interrupts or exceptions are involved .
122103
123- So the benefit of objtool here will be that external tooling should
124- always show perfect stack traces. And the same will be true for
125- kernel warning/oops traces if the architecture has a runtime DWARF
126- unwinder.
104+ For more details, see Documentation/x86/orc-unwinder.txt.
127105
128106c) Higher live patching compatibility rate
129107
@@ -211,7 +189,7 @@ they mean, and suggestions for how to fix them.
211189 function, add proper frame pointer logic using the FRAME_BEGIN and
212190 FRAME_END macros. Otherwise, if it's not a callable function, remove
213191 its ELF function annotation by changing ENDPROC to END, and instead
214- use the manual CFI hint macros in asm/undwarf .h.
192+ use the manual unwind hint macros in asm/unwind_hints .h.
215193
216194 If it's a GCC-compiled .c file, the error may be because the function
217195 uses an inline asm() statement which has a "call" instruction. An
@@ -231,8 +209,8 @@ they mean, and suggestions for how to fix them.
231209 If the error is for an asm file, and the instruction is inside (or
232210 reachable from) a callable function, the function should be annotated
233211 with the ENTRY/ENDPROC macros (ENDPROC is the important one).
234- Otherwise, the code should probably be annotated with the CFI hint
235- macros in asm/undwarf .h so objtool and the unwinder can know the
212+ Otherwise, the code should probably be annotated with the unwind hint
213+ macros in asm/unwind_hints .h so objtool and the unwinder can know the
236214 stack state associated with the code.
237215
238216 If you're 100% sure the code won't affect stack traces, or if you're
@@ -258,7 +236,7 @@ they mean, and suggestions for how to fix them.
258236 instructions aren't allowed in a callable function, and are most
259237 likely part of the kernel entry code. They should usually not have
260238 the callable function annotation (ENDPROC) and should always be
261- annotated with the CFI hint macros in asm/undwarf .h.
239+ annotated with the unwind hint macros in asm/unwind_hints .h.
262240
263241
2642426. file.o: warning: objtool: func()+0x26: sibling call from callable instruction with modified stack frame
@@ -272,7 +250,7 @@ they mean, and suggestions for how to fix them.
272250
273251 If the instruction is not actually in a callable function (e.g.
274252 kernel entry code), change ENDPROC to END and annotate manually with
275- the CFI hint macros in asm/undwarf .h.
253+ the unwind hint macros in asm/unwind_hints .h.
276254
277255
2782567. file: warning: objtool: func()+0x5c: stack state mismatch
@@ -288,8 +266,8 @@ they mean, and suggestions for how to fix them.
288266
289267 Another possibility is that the code has some asm or inline asm which
290268 does some unusual things to the stack or the frame pointer. In such
291- cases it's probably appropriate to use the CFI hint macros in
292- asm/undwarf .h.
269+ cases it's probably appropriate to use the unwind hint macros in
270+ asm/unwind_hints .h.
293271
294272
2952738. file.o: warning: objtool: funcA() falls through to next function funcB()
0 commit comments