joaomoreira added inline comments.
================ Comment at: clang/test/CodeGen/X86/x86-cf-protection.c:4 // RUN: %clang -target i386-unknown-unknown -x c -E -dM -o - -fcf-protection=full %s | FileCheck %s --check-prefix=FULL +// RUN: %clang -target i386-unknown-unknown -o - -emit-llvm -S -fcf-protection=branch -mibt-seal -flto %s | FileCheck %s --check-prefix=IBTSEAL ---------------- xiangzhangllvm wrote: > joaomoreira wrote: > > pengfei wrote: > > > Is `-flto` is required? > > Yes, we can only suppress ENDBR if we are sure the given function is not > > address taken in all other translation units. > Sorry, let me make sure here. what is the "translation units" here mean? Does > it means another binary file (e.g. *.so , *.a)? > Using -flto seems here want more compile units (source files) to be one > "translation units"? Translation unit means a source file translated into an object file. When compiling the kernel, we have different .c files that are translated into different .o files. Each .c translated into .o is a translation unit. Because a function might not be address taken in the translation unit where it is defined but could be address taken in a different one, we need to emit ENDBRs to all non-local (static) functions. With LTO this changes, because we can look at all to-be-generated objects and be sure that a given function is not address taken in any of the translation units. This optimization is kernel-specific because in user-space code non-local functions can be reached through the PLT of a different dynamically linked library (.so) or through dlsym, and this is impossible to predict in compilation time. In kernel, exported symbols are implicitly address taken. This way, if a module tries to take the address of an exported function, this would be ok. The optimization will mostly rule-out non-static functions that are not exported from receiving an ENDBR. The numeric benefits of the optimization are shown in https://reviews.llvm.org/D116070 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118052/new/ https://reviews.llvm.org/D118052 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
