forked from OSchip/llvm-project
0e497d1554
The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495 |
||
|---|---|---|
| .. | ||
| ABIInfo.h | ||
| Address.h | ||
| BackendUtil.cpp | ||
| CGAtomic.cpp | ||
| CGBlocks.cpp | ||
| CGBlocks.h | ||
| CGBuilder.h | ||
| CGBuiltin.cpp | ||
| CGCUDANV.cpp | ||
| CGCUDARuntime.cpp | ||
| CGCUDARuntime.h | ||
| CGCXX.cpp | ||
| CGCXXABI.cpp | ||
| CGCXXABI.h | ||
| CGCall.cpp | ||
| CGCall.h | ||
| CGClass.cpp | ||
| CGCleanup.cpp | ||
| CGCleanup.h | ||
| CGCoroutine.cpp | ||
| CGDebugInfo.cpp | ||
| CGDebugInfo.h | ||
| CGDecl.cpp | ||
| CGDeclCXX.cpp | ||
| CGException.cpp | ||
| CGExpr.cpp | ||
| CGExprAgg.cpp | ||
| CGExprCXX.cpp | ||
| CGExprComplex.cpp | ||
| CGExprConstant.cpp | ||
| CGExprScalar.cpp | ||
| CGGPUBuiltin.cpp | ||
| CGLoopInfo.cpp | ||
| CGLoopInfo.h | ||
| CGNonTrivialStruct.cpp | ||
| CGObjC.cpp | ||
| CGObjCGNU.cpp | ||
| CGObjCMac.cpp | ||
| CGObjCRuntime.cpp | ||
| CGObjCRuntime.h | ||
| CGOpenCLRuntime.cpp | ||
| CGOpenCLRuntime.h | ||
| CGOpenMPRuntime.cpp | ||
| CGOpenMPRuntime.h | ||
| CGOpenMPRuntimeNVPTX.cpp | ||
| CGOpenMPRuntimeNVPTX.h | ||
| CGRecordLayout.h | ||
| CGRecordLayoutBuilder.cpp | ||
| CGStmt.cpp | ||
| CGStmtOpenMP.cpp | ||
| CGVTT.cpp | ||
| CGVTables.cpp | ||
| CGVTables.h | ||
| CGValue.h | ||
| CMakeLists.txt | ||
| CodeGenABITypes.cpp | ||
| CodeGenAction.cpp | ||
| CodeGenFunction.cpp | ||
| CodeGenFunction.h | ||
| CodeGenModule.cpp | ||
| CodeGenModule.h | ||
| CodeGenPGO.cpp | ||
| CodeGenPGO.h | ||
| CodeGenTBAA.cpp | ||
| CodeGenTBAA.h | ||
| CodeGenTypeCache.h | ||
| CodeGenTypes.cpp | ||
| CodeGenTypes.h | ||
| ConstantEmitter.h | ||
| ConstantInitBuilder.cpp | ||
| CoverageMappingGen.cpp | ||
| CoverageMappingGen.h | ||
| EHScopeStack.h | ||
| ItaniumCXXABI.cpp | ||
| MacroPPCallbacks.cpp | ||
| MacroPPCallbacks.h | ||
| MicrosoftCXXABI.cpp | ||
| ModuleBuilder.cpp | ||
| ObjectFilePCHContainerOperations.cpp | ||
| PatternInit.cpp | ||
| PatternInit.h | ||
| README.txt | ||
| SanitizerMetadata.cpp | ||
| SanitizerMetadata.h | ||
| SwiftCallingConv.cpp | ||
| TargetInfo.cpp | ||
| TargetInfo.h | ||
| VarBypassDetector.cpp | ||
| VarBypassDetector.h | ||
README.txt
IRgen optimization opportunities. //===---------------------------------------------------------------------===// The common pattern of -- short x; // or char, etc (x == 10) -- generates an zext/sext of x which can easily be avoided. //===---------------------------------------------------------------------===// Bitfields accesses can be shifted to simplify masking and sign extension. For example, if the bitfield width is 8 and it is appropriately aligned then is is a lot shorter to just load the char directly. //===---------------------------------------------------------------------===// It may be worth avoiding creation of alloca's for formal arguments for the common situation where the argument is never written to or has its address taken. The idea would be to begin generating code by using the argument directly and if its address is taken or it is stored to then generate the alloca and patch up the existing code. In theory, the same optimization could be a win for block local variables as long as the declaration dominates all statements in the block. NOTE: The main case we care about this for is for -O0 -g compile time performance, and in that scenario we will need to emit the alloca anyway currently to emit proper debug info. So this is blocked by being able to emit debug information which refers to an LLVM temporary, not an alloca. //===---------------------------------------------------------------------===// We should try and avoid generating basic blocks which only contain jumps. At -O0, this penalizes us all the way from IRgen (malloc & instruction overhead), all the way down through code generation and assembly time. On 176.gcc:expr.ll, it looks like over 12% of basic blocks are just direct branches! //===---------------------------------------------------------------------===//