LLD fails to link a kernel with LTO and DYNAMIC_FTRACE_WITH_REGS

[samitolvanen]

DYNAMIC_FTRACE_WITH_REGS turns on -fpatchable-function-entry=2, which results in the following errors from LLD during the final linking steps of vmlinux:

ld.lld: error: incompatible section flags for .init.data
>>> vmlinux.o:(__patchable_function_entries): 0x83
>>> output section .init.data: 0x3

ld.lld: error: incompatible section flags for .init.data
>>> <internal>:(.init.rodata.cst16): 0x12
>>> output section .init.data: 0x83

ld.lld: error: incompatible section flags for .init.data
>>> <internal>:(.init.rodata.str1.1): 0x32
>>> output section .init.data: 0x93

ld.lld: error: incompatible section flags for .init.data
>>> vmlinux.o:(.init.rodata): 0x12
>>> output section .init.data: 0xB3

ld.lld: error: incompatible section flags for .init.data
>>> vmlinux.o:(_ftrace_events): 0x3
>>> output section .init.data: 0xB3
...

Looking at the flags, __patchable_function_entries sections have the LINK ORDER flag set while it's not set for the other sections the kernel merges to .init.data in include/asm-generic/vmlinux.lds.h:

#define MCOUNT_REC()    . = ALIGN(8);                           \
                        __start_mcount_loc = .;                 \
                        KEEP(*(__mcount_loc))                   \
                        KEEP(*(__patchable_function_entries))   \
                        __stop_mcount_loc = .;                  \
                        ftrace_stub_graph = ftrace_stub;
...
#define INIT_DATA                                                       \
        KEEP(*(SORT(___kentry+*)))                                      \
        *(.init.data init.data.*)                                       \
        MEM_DISCARD(init.data*)                                         \
        KERNEL_CTORS()                                                  \
        MCOUNT_REC()                                                    \
...

I can reproduce the error with the following trivial example:

$ cat main.c
#define __section(S)    __attribute__((__section__(#S)))
#define __initdata      __section(.init.data)

static int a __initdata = 1;

int main()
{
        a = a - 1;
        return a;
}
$ cat init.lds 
SECTIONS {
        .init.data : {
                *(.init.data)
                *(__patchable_function_entries)
        }
}
$ clang -flto=thin -fvisibility=default -fpatchable-function-entry=2 \
-fuse-ld=lld -Wl,-T init.lds main.c
ld.lld: error: incompatible section flags for .init.data
>>> lto.tmp:(__patchable_function_entries): 0x83
>>> output section .init.data: 0x3
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

@nickdesaulniers @MaskRay Does this look like the kernel is doing something wrong, or is this a bug in LLVM?

[MaskRay]

Can you share your LTO configuration? I am not familiar with these configurations. It seems that somewhere -fno-integrated-as is not used. When the integrated assembler is used, __patchable_function_entries will have the SHF_LINK_ORDER flag. I chose SHF_LINK_ORDER for clang because it is the only way solving a number of issues: https://gcc.gnu.org/legacy-ml/gcc/2020-01/msg00067.html

I did not know what the kernel place __patchable_function_entries with .init.data (non-SHF_LINK_ORDER). Mixing SHF_LINK_ORDER and non-SHF_LINK_ORDER in an output section is not great. The semantic of SHF_LINK_ORDER has been extended, but its original semantic still appllies. The ELF spec says:

This flag adds special ordering requirements for link editors. The requirements apply if the sh_link field of this section's header references another section (the linked-to section). If this section is combined with other sections in the output file, it must appear in the same relative order with respect to those sections, as the linked-to section appears with respect to sections the linked-to section is combined with.

It is not clear how a mixed output section should be used. One definition is that SHF_LINK_ORDER sections in an output section should be sorted among its group. If an output sections consists of input sections normal0 normal1 linkorder0 linkorder1 linkorder2 normal2, linkorder should be sorted. normal should keep their positions. Things can get more complex if there are different SHF_LINK_ORDER sections. All these stuff adds quite a bit complexity to the linker :/

Created https://reviews.llvm.org/D77007

(I can figure out a solution if I know how to test...)

[samitolvanen]

Can you share your LTO configuration?

Sure, here's the arm64 .config I used with my LTO/CFI tree, and here are the commands I used to generate it and build the kernel:

MAKE_ARGS="ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm"

make $MAKE_ARGS mrproper -j && \
make $MAKE_ARGS defconfig && \
./scripts/config \
        -e RCU_TORTURE_TEST \
        -e LOCK_TORTURE_TEST \
        -e MODVERSIONS \
        -e LTO_CLANG -e THINLTO \
        -e FTRACE -e FUNCTION_TRACER -e DYNAMIC_FTRACE \
make $MAKE_ARGS olddefconfig && \
make $MAKE_ARGS -j110

I am not familiar with these configurations. It seems that somewhere -fno-integrated-as is not used.

LTO uses the integrated assembler for inline assembly always, ignoring -fno-integrated-as.

(I can figure out a solution if I know how to test...)

Is the stand-alone reproducer above not a sufficient test case?

[MaskRay]

@samitolvanen I'll try out your https://github.com/samitolvanen/linux/commits/clang-cfi later. Can you verify whether https://reviews.llvm.org/D77007 fixed the problem? I committed it a few hours ago.

[samitolvanen]

Yes, that fixes it. gdb still complains about BFD: vmlinux: warning: sh_link not set for section .init.data'`, but the kernel builds and boots, so I'll mark this as closed. Thanks!

[MaskRay]

.init.data mixes non-SHF_LINK_ORDER and SHF_LINK_ORDER. It gets the flag due to logic OR.

The first section of .init.data is a non-SHF_LINK_ORDER, thus lld arbitrarily sets sh_link to 0. It is not clear what we should do here. https://reviews.llvm.org/D76410 has some discussions. sh_link should not matter at runtime, though.

[nathanchance]

This is broken in LLVM 10.0.0 because -fpatchable-function-entry showed up then. Getting this applied to LLVM 10.0.1 would be nice. Aside from the test changes, it applies cleanly and I can verify that the issue is fixed.

[nickdesaulniers]

cc @tstellar

[tstellar]

Upstream tacking bug: https://llvm.org/PR45376