Lines Matching refs:to
18 - Stack unwinding metadata validation -- useful for helping to ensure
22 alternative to frame pointer based unwinding
28 sites, enabling the kernel to patch them inline, to prevent "thunk
36 kernel to implement inline static calls, a faster alternative to some
46 to ensure that all functions referenced by function pointers have
50 instruction sites, enabling the kernel to "seal" them (replace them
51 with NOPs) to further harden IBT
107 alternative execution paths to a given instruction (or set of
108 instructions). Similarly, it knows how to follow switch statements, for
116 code and debug tools to be able to walk the stack to determine the
117 chain of function call sites that led to the currently executing
122 required by the ABI (sometimes referred to as "backchain pointers").
127 But for asm code, the frame setup instructions have to be written by
131 For stack traces based on frame pointers to be reliable, all
165 skipped. Instead the stack trace seems to show that
179 An alternative to frame pointers and DWARF, ORC unwind data can be
180 used to walk the stack. Unlike frame pointers, ORC data is out of
189 more complex patches. In order for the consistency model to work,
190 stack traces need to be reliable (or an unreliable condition needs to
205 callable function in order to analyze its stack metadata.
212 Such code doesn't have to follow any of the other rules.
224 4. Dynamic jumps and jumps to undefined symbols are only allowed if:
232 function's code paths. If a function jumps to code in another file,
233 and it's not a sibling call, objtool has no way to follow the jump
240 This rule is just a sanity check to ensure that callable functions
249 output, including any disassembly or backtrace below the warning, to the
255 For C files, the common culprits are inline asm statements and calls to
259 -fno-omit-frame-pointer or adds -fomit-frame-pointer to the gcc options.
262 they mean, and suggestions for how to fix them. When in doubt, ping
274 its ELF function annotation by changing ENDPROC to END, and instead
290 Objtool couldn't find a code path to reach the instruction.
300 a just a bad person, you can tell objtool to ignore it. See the
304 change ENDPROC to END.
308 The call from foo() to bar() doesn't return, but bar() is missing the
309 __noreturn annotation. NOTE: In addition to annotating the function
310 with __noreturn, please also add it to tools/objtool/noreturns.h.
317 objtool's instruction decoder. Move the data to a more appropriate
332 This is a dynamic jump or a jump to an undefined symbol. Objtool
334 wasn't first restored to its original state.
336 If it's not really a sibling call, you may need to move the
337 destination code to the local file.
340 kernel entry code), change ENDPROC to END and annotate manually with
347 which execution path was taken to reach the instruction.
356 does some unusual things to the stack or the frame pointer. In such
357 cases it's probably appropriate to use the unwind hint macros in
361 8. file.o: warning: objtool: funcA() falls through to next function funcB()
368 1) funcA()'s last instruction is a call to a "noreturn" function like
369 panic(). In this case the noreturn function needs to be added to
370 objtool's hard-coded global_noreturns array. Feel free to bug the
377 might be corrupt due to a gcc bug. For more details, see:
380 9. file.o: warning: objtool: funcA() call to funcB() with UACCESS enabled
382 This means that an unexpected call to a non-whitelisted function exists
387 These functions should be called to denote a minimal critical section around
388 access to __user variables. See also: https://lwn.net/Articles/517475/
390 The intention of the warning is to prevent calls to funcB() from eventually
394 It also helps verify that there are no unexpected calls to funcB() which may
398 1) remove explicit calls to funcB() from funcA().
399 2) add the correct guards before and after calls to low level functions like
401 3) add funcB to uaccess_safe_builtin whitelist in tools/objtool/check.c, if
409 macro, the code paths have conflicting modifications to the stack.
414 NOPs to shift the stack changes around so they no longer conflict.
418 This warning means that a direct call is done to a destination which
426 to be an indirect call target is not. In particular, this happens for
428 names and does not use module_init() / module_exit() macros to create
432 If the error doesn't seem to make sense, it could be a bug in objtool.
433 Feel free to ask the objtool maintainer for help.
439 If you _really_ need objtool to ignore something, and are 100% sure
440 that it won't affect kernel stack traces, you can tell objtool to
450 to the Makefile.
456 to the Makefile.