Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

warning: objtool: missing symbol for insn at offset 0x3e #1209

Closed
arndb opened this issue Dec 4, 2020 · 26 comments
Closed

warning: objtool: missing symbol for insn at offset 0x3e #1209

arndb opened this issue Dec 4, 2020 · 26 comments
Assignees
Labels
[BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 5.11 This bug was fixed in Linux 5.11 [TOOL] integrated-as The issue is relevant to LLVM integrated assembler [TOOL] objtool warning is produced by the kernel's objtool

Comments

@arndb
Copy link

arndb commented Dec 4, 2020

This happens on x86 randconfigs, currently looking at linux-next-20201203:

arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn at offset 0x3e

Example .config: https://pastebin.com/wwwhUL8L

@ihalip
Copy link

ihalip commented Dec 5, 2020

I assume this happens with LLVM_IAS=1, it's how I reproduced it. Looks like in this case, some section symbols are not being output.

Symbol table '.symtab' contains 8 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 SECTION LOCAL  DEFAULT    1                <---- missing with LLVM_IAS=1
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    3                <---- missing with LLVM_IAS=1
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4                <---- missing with LLVM_IAS=1
     4: 0000000000000000    24 FUNC    GLOBAL DEFAULT    1 preempt_schedule_thunk
     5: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND preempt_schedule
     6: 0000000000000018    24 FUNC    GLOBAL DEFAULT    1 preempt_schedule_notrace_
     7: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND preempt_schedule_notrace

@nickdesaulniers
Copy link
Member

Looks like in this case, some section symbols are not being output.

Yes, this is a known difference where objtool has been patched in the past. So then sounds like something may have changed possibly in objtool to rely on the section symbols, again. But the warning is about a symbol for an instruction; I wouldn't expect section symbols to be related to instructions. See also: #669 (comment)

@nickdesaulniers nickdesaulniers added [BUG] Untriaged Something isn't working [TOOL] objtool warning is produced by the kernel's objtool [TOOL] integrated-as The issue is relevant to LLVM integrated assembler labels Dec 7, 2020
@nickdesaulniers
Copy link
Member

cc @jcai19 @groeck looks like CrOS just hit this as well.

@groeck
Copy link

groeck commented Dec 11, 2020

Yes. Unfirtunately is all but impossible for "outsiders" to determine if this is a llvm assembler problem or an objtool problem or maybe both.

@nickdesaulniers
Copy link
Member

in the bad case, arch/x86/entry/thunk_64.s does not define:
STATIC_JUMP_IF_TRUE
STATIC_JUMP_IF_FALSE
SET_NOFLUSH_BIT
ADJUST_KERNEL_CR3
SWITCH_TO_KERNEL_CR3
SWITCH_TO_USER_CR3_NOSTACK
SWITCH_TO_USER_CR3_STACK
SAVE_AND_SWITCH_TO_KERNEL_CR3
RESTORE_CR3
LOAD_CPU_AND_NODE_SEG_LIMIT

GET_PERCPU_BASE looks like just pcpu_unit_offsets(%rip), \reg. ___EXPORT_SYMBOL looks different. there's thunks for preempt_schedule_thunk and preempt_schedule_notrace_thunk and a .L_restore symbol.

So CONFIG_PREEMPTION=y (bad), CONFIG_SMP=n (bad), CONFIG_PAGE_TABLE_ISOLATION=n (bad). But those alone on top of defconfig are not enough to repro. I'm having trouble pinning down the configs via tools/testing/ktest/config-bisect.pl.

@nickdesaulniers
Copy link
Member

$ clang -Wp,-MMD,arch/x86/entry/.thunk_64.o.d -nostdinc -isystem /android0/llvm-project/llvm/build/lib/clang/12.0.0/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Qunused-arguments -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -Werror=unknown-warning-option -m64 -DCONFIG_X86_X32_ABI    -c -o arch/x86/entry/thunk_64.o arch/x86/entry/thunk_64.S
$ ./tools/objtool/objtool orc generate  --no-fp --no-unreachable --retpoline arch/x86/entry/thunk_64.o
arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn at offset 0x3e
$ llvm-objdump -Dr arch/x86/entry/thunk_64.o
0000000000000018 <preempt_schedule_notrace_thunk>:
...
      3e: c3                            retq

Even with Josh's patch from https://groups.google.com/g/clang-built-linux/c/1C6YoJKBsQQ/m/a8IS1NjGAgAJ applied.

@nickdesaulniers
Copy link
Member

insn_to_reloc_sym_addend() calls find_symbol_containing twice; once with offset, once with offset - 1. Both calls return NULL in the bad config.

@jpoimboe
Copy link

Can somebody attach the .o file? Not sure why my mailer's rejecting it.

@nickdesaulniers
Copy link
Member

thunk_64.o.txt
cc @jpoimboe

@jpoimboe
Copy link

The problem is this code segment at the bottom of arch/x86/entry/thunk_64.S. With the LLVM assembler stripping the .text section symbol, objtool has no way to reference this code when it generates ORC unwinder entries, because this code is outside of any ELF function.

SYM_CODE_START_LOCAL_NOALIGN(.L_restore)
        popq %r11
        popq %r10
        popq %r9
        popq %r8
        popq %rax
        popq %rcx
        popq %rdx
        popq %rsi
        popq %rdi
        popq %rbp
        ret
        _ASM_NOKPROBE(.L_restore)
SYM_CODE_END(.L_restore)

@jpoimboe
Copy link

jpoimboe commented Dec 23, 2020

I don't have access to this assembler at the moment, but is there a way to encourage it to not strip the ".text" section symbol in this file, either with a flag or some trick to create a section reference?

@jpoimboe
Copy link

jpoimboe commented Dec 23, 2020

Something like the below would probably fix it, by forcing the code into an ELF symbol.

Still, it would be really nice to have a flag to turn off the section symbol stripping, as I don't think it has any benefits for the kernel (and it definitely has drawbacks for cases like this).

diff --git a/arch/x86/entry/thunk_64.S b/arch/x86/entry/thunk_64.S
index ccd32877a3c4..4920037445fb 100644
--- a/arch/x86/entry/thunk_64.S
+++ b/arch/x86/entry/thunk_64.S
@@ -44,7 +44,7 @@ SYM_FUNC_END(\name)
 #endif
 
 #ifdef CONFIG_PREEMPTION
-SYM_CODE_START_LOCAL_NOALIGN(.L_restore)
+SYM_CODE_START_GLOBAL_NOALIGN(__thunk_restore)
        popq %r11
        popq %r10
        popq %r9
@@ -56,6 +56,6 @@ SYM_CODE_START_LOCAL_NOALIGN(.L_restore)
        popq %rdi
        popq %rbp
        ret
-       _ASM_NOKPROBE(.L_restore)
-SYM_CODE_END(.L_restore)
+       _ASM_NOKPROBE(__thunk_restore)
+SYM_CODE_END(__thunk_restore)
 #endif

@nickdesaulniers
Copy link
Member

I don't have access to this assembler at the moment, but is there a way to encourage it to not strip the ".text" section symbol in this file, either with a flag or some trick to create a section reference?

@MaskRay didn't we have a thread about this previously? I don't think adding support for emitting symbols for sections would be too bad.

@nickdesaulniers
Copy link
Member

llvm/llvm-project@a401eee seems relevant.

diff --git a/llvm/lib/MC/ELFObjectWriter.cpp b/llvm/lib/MC/ELFObjectWriter.cpp
index 10c61fc8b453..bb9089ebe85b 100644
--- a/llvm/lib/MC/ELFObjectWriter.cpp
+++ b/llvm/lib/MC/ELFObjectWriter.cpp
@@ -598,9 +598,6 @@ bool ELFWriter::isInSymtab(const MCAsmLayout &Layout, const MCSymbolELF &Symbol,
   if (Symbol.isTemporary())
     return false;
 
-  if (Symbol.getType() == ELF::STT_SECTION)
-    return false;
-
   return true;
 }

is enough to restore the behavior of emitting section symbols; would just need to clean up the resulting test failures.

Failed Tests (17):
LLVM :: CodeGen/PowerPC/pcrel-tls-general-dynamic.ll
LLVM :: CodeGen/PowerPC/pcrel-tls-initial-exec.ll
LLVM :: ExecutionEngine/JITLink/X86/ELF_x86-64_relocations.s
LLVM :: MC/AArch64/size-directive.s
LLVM :: MC/ELF/alias.s
LLVM :: MC/ELF/cgprofile.s
LLVM :: MC/ELF/comdat.s
LLVM :: MC/ELF/empty.s
LLVM :: MC/ELF/reloc-same-name-section.s
LLVM :: MC/ELF/relocation-alias.s
LLVM :: MC/ELF/section-sym.s
LLVM :: MC/ELF/undef.s
LLVM :: tools/llvm-objdump/X86/demangle.s
LLVM :: tools/llvm-readobj/ELF/many-sections2.s
lld :: ELF/error-handling-script-linux.test
lld :: ELF/icf-safe.s
lld :: ELF/lto/thinlto-single-module.ll

@nickdesaulniers
Copy link
Member

nickdesaulniers commented Dec 23, 2020

WIP: https://reviews.llvm.org/D93783 let's see what the feedback is. Fixes the reported issue.

@nickdesaulniers
Copy link
Member

@nickdesaulniers nickdesaulniers added the [PATCH] Submitted A patch has been submitted for review label Dec 23, 2020
@nickdesaulniers nickdesaulniers self-assigned this Dec 23, 2020
@MaskRay
Copy link
Member

MaskRay commented Dec 23, 2020

Replied on https://reviews.llvm.org/D93783#2470728
I understand it is a (continuous) pain for objtool but we probably should take it. The LLVM integrated assembler behavior is very much desired and emitting unneeded STT_SECTION can cause unneeded .o size bloat for many users. GNU as feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27109 (I thought I had reported this earlier but it turned out that I hadn't. oops)

@jpoimboe
Copy link

Fair enough, it does make sense for '-ffunction-sections' at least.

fengguang pushed a commit to 0day-ci/linux that referenced this issue Dec 24, 2020
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 (use Clang's integrated assembler). Josh
notes:

  With the LLVM assembler stripping the .text section symbol, objtool
  has no way to reference this code when it generates ORC unwinder
  entries, because this code is outside of any ELF function.

This behavior was implemented as an optimization in LLVM 5 years ago,
but it's not the first time this has caused issues for objtool.  A patch
has been authored against LLVM to revert the behavior, which may or may
not be accepted.  Until then use a global symbol for the thunk that way
objtool can generate proper unwind info here with LLVM_IAS=1.

Cc: Fangrui Song <maskray@google.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: ClangBuiltLinux#1209
Link: https://reviews.llvm.org/D93783
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
@arndb
Copy link
Author

arndb commented Jan 5, 2021

I see a second produce a similar warning

arch/x86/kernel/ftrace_64.o: warning: objtool: missing symbol for insn at offset 0x16

0xE5F582C9-config.gz

@nickdesaulniers
Copy link
Member

HJL posted a patch for GAS to omit STT_SECTION symbols as well: https://sourceware.org/pipermail/binutils/2020-December/114671.html

@jpoimboe
Copy link

jpoimboe commented Jan 5, 2021

I see a second produce a similar warning

arch/x86/kernel/ftrace_64.o: warning: objtool: missing symbol for insn at offset 0x16

0xE5F582C9-config.gz

This one's slightly different.

Symbol table '.symtab' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    4 __ksym_marker___[...]
     2: 000000000000000e     0 NOTYPE  LOCAL  DEFAULT    2 fgraph_trace
     3: 000000000000000f     0 NOTYPE  LOCAL  DEFAULT    2 trace
     4: 0000000000000000   165 FUNC    GLOBAL DEFAULT    2 __fentry__
     5: 000000000000000e     0 NOTYPE  GLOBAL DEFAULT    2 ftrace_stub
     6: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND ftrace_trace_function

The instruction at 0x16 is inside the __fentry__ function, but objtool can't figure that out because its red-black tree of symbols is sorted by offset and it gets confused by the fact that the NOTYPE symbols overlap the function.

This will probably need an objtool fix.

@jpoimboe
Copy link

jpoimboe commented Jan 7, 2021

Fix for this 2nd issue posted:
https://lkml.kernel.org/r/9638ee49574226218d978ce7e26f7a107021f509.1609990368.git.jpoimboe@redhat.com

@nickdesaulniers
Copy link
Member

@nickdesaulniers
Copy link
Member

accepted: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/entry&id=bde718b7e154afc99e1956b18a848401ce8e1f8e

@nickdesaulniers nickdesaulniers added [BUG] linux A bug that should be fixed in the mainline kernel. [PATCH] Accepted A submitted patch has been accepted upstream and removed [BUG] Untriaged Something isn't working [PATCH] Submitted A patch has been submitted for review labels Jan 13, 2021
@nickdesaulniers
Copy link
Member

Looks like CrOS just hit this issue.

samitolvanen pushed a commit to samitolvanen/linux that referenced this issue Jan 21, 2021
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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
@dileks
Copy link
Collaborator

dileks commented Jan 31, 2021

@dileks dileks added [FIXED][LINUX] 5.11 This bug was fixed in Linux 5.11 and removed [PATCH] Accepted A submitted patch has been accepted upstream labels Jan 31, 2021
@dileks dileks closed this as completed Jan 31, 2021
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Feb 3, 2021
commit 5e6dca8 upstream.

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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux/linux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
Cc: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
evdenis pushed a commit to evdenis/linux-floppy that referenced this issue Feb 4, 2021
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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
zhantaotang pushed a commit to zhantaotang/linux-yocto that referenced this issue Feb 19, 2021
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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux/linux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
it-is-a-robot pushed a commit to openeuler-mirror/raspberrypi-kernel that referenced this issue Feb 24, 2021
stable inclusion
from stable-5.10.13
commit 4c973f75074af1422c7f0ef1a3781b60594f64c8
bugzilla: 47995

--------------------------------

commit 5e6dca8 upstream.

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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux/linux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
Cc: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
Acked-by: Xie XiuQi <xiexiuqi@huawei.com>
cythe pushed a commit to cythe/linux that referenced this issue Feb 24, 2021
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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
wataash pushed a commit to wataash/linux that referenced this issue Apr 29, 2021
BugLink: https://bugs.launchpad.net/bugs/1918516

commit 5e6dca8 upstream.

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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
Cc: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
eatradish pushed a commit to AOSC-Tracking/linux that referenced this issue Jun 8, 2021
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@arndb.de>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com
Link: ClangBuiltLinux#1209
Link: https://reviews.llvm.org/D93783
Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 5.11 This bug was fixed in Linux 5.11 [TOOL] integrated-as The issue is relevant to LLVM integrated assembler [TOOL] objtool warning is produced by the kernel's objtool
Projects
None yet
Development

No branches or pull requests

7 participants