summaryrefslogtreecommitdiffstats
path: root/tools/objtool/check.c
diff options
context:
space:
mode:
authorPeter Zijlstra <peterz@infradead.org>2020-04-16 14:34:26 +0200
committerPeter Zijlstra <peterz@infradead.org>2020-04-30 20:14:34 +0200
commitcc1ac9c792810b93783a7de344f428922af8d98c (patch)
tree33da496a06b118211f1178a55f3d30d51f96abec /tools/objtool/check.c
parent34fdce6981b96920ced4e0ee56e9db3fb03a33f0 (diff)
downloadlinux-stable-cc1ac9c792810b93783a7de344f428922af8d98c.tar.gz
linux-stable-cc1ac9c792810b93783a7de344f428922af8d98c.tar.bz2
linux-stable-cc1ac9c792810b93783a7de344f428922af8d98c.zip
x86/retpoline: Fix retpoline unwind
Currently objtool cannot understand retpolines, and thus cannot generate ORC unwind information for them. This means that we cannot unwind from the middle of a retpoline. The recent ANNOTATE_INTRA_FUNCTION_CALL and UNWIND_HINT_RET_OFFSET support in objtool enables it to understand the basic retpoline construct. A further problem is that the ORC unwind information is alternative invariant; IOW. every alternative should have the same ORC, retpolines obviously violate this. This means we need to out-of-line them. Since all GCC generated code already uses out-of-line retpolines, this should not affect performance much, if anything. This will enable objtool to generate valid ORC data for the out-of-line copies, which means we can correctly and reliably unwind through a retpoline. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200428191700.210835357@infradead.org
Diffstat (limited to 'tools/objtool/check.c')
0 files changed, 0 insertions, 0 deletions