On Thu, Jan 14, 2021 at 11:39:28AM +0100, Borislav Petkov wrote: > From: Nick Desaulniers <ndesaulniers@xxxxxxxxxx> > 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 <arnd@xxxxxxxx> > Suggested-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > Suggested-by: Borislav Petkov <bp@xxxxxxxxx> > Suggested-by: Mark Brown <broonie@xxxxxxxxxx> > Signed-off-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx> > Signed-off-by: Borislav Petkov <bp@xxxxxxx> Acked-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx> And while looking, I suppose we can delete the put_ret_addr_in_rdi crud, but that's another patch.
