On Thu, Jan 14, 2021 at 11:39:28AM +0100, Borislav Petkov wrote: > From: Nick Desaulniers <[email protected]> > Date: Tue, 12 Jan 2021 11:46:24 -0800 > Subject: [PATCH] x86/entry: Emit a symbol for register restoring thunk > > Arnd found a randconfig that produces the warning: > > arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn at > offset 0x3e > > when building with LLVM_IAS=1 (Clang's integrated assembler). Josh > notes: > > With the LLVM assembler not generating section symbols, objtool has no > way to reference this code when it generates ORC unwinder entries, > because this code is outside of any ELF function. > > The limitation now being imposed by objtool is that all code must be > contained in an ELF symbol. And .L symbols don't create such symbols. > > So basically, you can use an .L symbol *inside* a function or a code > segment, you just can't use the .L symbol to contain the code using a > SYM_*_START/END annotation pair. > > Fangrui notes that this optimization is helpful for reducing image size > when compiling with -ffunction-sections and -fdata-sections. I have > observed on the order of tens of thousands of symbols for the kernel > images built with those flags. > > A patch has been authored against GNU binutils to match this behavior > of not generating unused section symbols ([1]), so this will > also become a problem for users of GNU binutils once they upgrade to 2.36. > > Omit the .L prefix on a label so that the assembler will emit an entry > into the symbol table for the label, with STB_LOCAL binding. This > enables objtool to generate proper unwind info here with LLVM_IAS=1 or > GNU binutils 2.36+. > > [ bp: Massage commit message. ] > > Reported-by: Arnd Bergmann <[email protected]> > Suggested-by: Josh Poimboeuf <[email protected]> > Suggested-by: Borislav Petkov <[email protected]> > Suggested-by: Mark Brown <[email protected]> > Signed-off-by: Nick Desaulniers <[email protected]> > Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]> And while looking, I suppose we can delete the put_ret_addr_in_rdi crud, but that's another patch.
