Linux: Cannot find symbol for section 2: .text.

[E5ten]

Using AS=clang to build with integrated-as, on x86_64, when scripts/recordmcount is run on certain objects (for me it happens with init/initramfs.o and kernel/elfcore.o at least) I get the error in the title.

[nathanchance]

Steps to reproduce (from #986):

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

$ cd linux

$ curl -LSs https://gist.github.com/nathanchance/171b7d672e311b56b4329821b8a43acd/raw/9a1dbb1f11552d0b6efec48ac29505dd0c768d1b/20200401_jpoimboe_objtool_fixes.mbx | git apply -3v

$ curl -LSs https://lore.kernel.org/lkml/[email protected]/raw | git apply -3v

$ ./scripts/config --file arch/x86/configs/x86_64_defconfig -e FUNCTION_TRACER

$ make -j$(nproc) -s LLVM=1 LLVM_IAS=1 O=out/x86_64 distclean defconfig bzImage

[E5ten]

I did an integrated-as build and specifically added CFLAGS_.o += -no-integrated-as to the relevant Makefile's for init/initramfs.o and kernel/elfcore.o, and got through the rest of the build, so at least for my configuration, those are the only 2 objects this issue happens with.

[E5ten]

I assume something like this also needs to be done for recordmcount to fix this?
https://lore.kernel.org/lkml/[e-mail]/

[dileks]

Just to clarify:
You use here LLVM_IAS=1 together with LLVM=1.

[E5ten]

yeah.

[dileks]

@E5ten

I switched over to use LLVM_IAS=1 together with LLVM=1.

[samitolvanen]

I also ran into this with LLVM_IAS=1 when building x86_64 defconfig with dynamic ftrace. Testing Peter's objtool mcount patch, I noticed that objtool segfaults for several object files because the files are missing STT_SECTION symbols for some of the sections.

A random example, compiled with LLVM_IAS=1:

$ readelf --sections arch/x86/mm/hugetlbpage.o | grep PROGBITS
  [ 2] .text             PROGBITS         0000000000000000  00000240
  [ 4] .altinstructions  PROGBITS         0000000000000000  000007c8
  [ 6] .altinstr_re[...] PROGBITS         0000000000000000  00000890
  [ 8] .altinstr_aux     PROGBITS         0000000000000000  000008d0
  [10] .init.text        PROGBITS         0000000000000000  00000988
...
$ readelf --symbols arch/x86/mm/hugetlbpage.o | grep SECTION
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    6 
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    8 

Objtool fails here because .init.text doesn't have a corresponding STT_SECTION symbol. Without IAS, the symbol is generated:

$ readelf --sections arch/x86/mm/hugetlbpage.o | grep PROGBITS
  [ 1] .text             PROGBITS         0000000000000000  00000040
  [ 3] .data             PROGBITS         0000000000000000  000005c8
  [ 5] .altinstructions  PROGBITS         0000000000000000  000005c8
  [ 7] .altinstr_re[...] PROGBITS         0000000000000000  00000690
  [ 9] .altinstr_aux     PROGBITS         0000000000000000  000006d0
  [11] .init.text        PROGBITS         0000000000000000  00000788
...
$ readelf --symbols arch/x86/mm/hugetlbpage.o | grep SECTION
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    7 
     7: 0000000000000000     0 SECTION LOCAL  DEFAULT    9 
     9: 0000000000000000     0 SECTION LOCAL  DEFAULT   11 
... 

Edit: OK, my issue looks similar to issue #669, but just in a different part of objtool. Specifically, the new static call processing code and the proposed mcount patch both depend on section symbols, so if either of these occur in a section for which a symbol is missing, objtool is going to segfault. This doesn't appear to be a problem with static calls right now (or we would have noticed it), but the mcount patch triggers this quite often. I fixed this in commit 54d837e5119bd5a15593820ca1585ca4e4f3e2a4 for now.

[nickdesaulniers]

It sounds like CrOS is hitting this now trying to move to LLVM_IAS=1: https://bugs.chromium.org/p/chromium/issues/detail?id=1148073 cc @jcai19

[nickdesaulniers]

With defconfig+FUNCTION_TRACER, I see this in:

init/initramfs.o
kernel/elfcore.o

Sami, I think https://github.com/ClangBuiltLinux/linux/commit/54d837e5119bd5a15593820ca1585ca4e4f3e2a4 no longer applies on linux-next?

[samitolvanen]

Sami, I think 54d837e no longer applies on linux-next?

That's because it only fixes the mcount pass (commit 0271fa5f8566b79f07c905922321ecc70b697b4c), which isn't upstream yet. You probably need an identical fix for the static call pass instead, assuming that's where it crashes.

[jcai19]

Sami, I think 54d837e no longer applies on linux-next?

That's because it only fixes the mcount pass (commit 0271fa5), which isn't upstream yet.

May I know what dependencies are needed to back port https://github.com/ClangBuiltLinux/linux/commit/0271fa5f8566b79f07c905922321ecc70b697b4c and https://github.com/ClangBuiltLinux/linux/commit/54d837e5119bd5a15593820ca1585ca4e4f3e2a4 into 5.4? While trying to test them on 5.4, I realized there were many dependencies I needed to cherry-pick/back-port in order to apply these two patches cleanly. For example, https://github.com/ClangBuiltLinux/linux/commit/0271fa5f8566b79f07c905922321ecc70b697b4c seems to be based on upstream commit 0f1441b44e823a74f3f3780902a113e07c73fbf6, which is not in 5.4 yet, but I could not cherry-pick it into stable/linux-5.4.y branch cleanly as its dependencies were also missing.

You probably need an identical fix for the static call pass instead, assuming that's where it crashes.

Just to be clear, does that mean https://github.com/ClangBuiltLinux/linux/commit/0271fa5f8566b79f07c905922321ecc70b697b4c and https://github.com/ClangBuiltLinux/linux/commit/54d837e5119bd5a15593820ca1585ca4e4f3e2a4 are not enough to fix this issue? Thanks.

[samitolvanen]

Just to be clear, does that mean 0271fa5 and 54d837e are not enough to fix this issue? Thanks.

After actually looking at the CrOS bug, I'm guessing it's the same as the original recordmcount issue and these objtool patches are not going to help here. Both issues have the same root cause though, Clang not always generating section symbols, but you'll need to fix this in recordmcount instead.

[nickdesaulniers]

I think @arndb just sent patches for this that got picked up by akpm: https://lore.kernel.org/lkml/[email protected]/

[arndb]

The patches I sent just work around the problem by avoiding the weak functions in those files, the bug is still there and could show up any time another file has only weak functions in the .text section.

[E5ten]

With these patches I was able to build and boot an x86_64 kernel with LLVM=1 and LLVM_IAS=1

[dileks]

Both patches in Linux v5.10 and linux-stable trees recently carrying them.

$ git log --oneline | grep 'initramfs: fix clang build failure'
55d5b7dd6451 initramfs: fix clang build failure
$ git describe --contains 55d5b7dd6451
v5.10~14^2~3

$ git log --oneline | grep 'elfcore: fix building with clang'
6e7b64b9dd6d elfcore: fix building with clang
$ git describe --contains 6e7b64b9dd6d
v5.10~14^2~2