Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-08-09T22:31:59+00:00 2019-08-09T22:31:59+00:00 Peter Collingbourne peter@pcc.me.uk 2019-08-09T22:31:59+00:00 urn:sha1:0e497d1554a915ace538dc08f03f1661aab8bdf7 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 2019-07-29T17:22:40+00:00 Peter Collingbourne peter@pcc.me.uk 2019-07-29T17:22:40+00:00 urn:sha1:dd9682196be6741879c76fa12e89164537d1f96d Globals that are associated with globals with type metadata need to appear in the merged module because they will reference the global's section directly. Differential Revision: https://reviews.llvm.org/D65312 llvm-svn: 367242 2019-06-17T09:51:07+00:00 Fangrui Song maskray@google.com 2019-06-17T09:51:07+00:00 urn:sha1:ac14f7b10cffe2be548607269e036244cd16acc3 llvm-svn: 363538 2019-05-15T02:35:32+00:00 Fangrui Song maskray@google.com 2019-05-15T02:35:32+00:00 urn:sha1:f4dfd63c74899e2953b176de2174ae7a8924a72c The 3-field form was introduced by D3499 in 2014 and the legacy 2-field form was planned to be removed in LLVM 4.0 For the textual format, this patch migrates the existing 2-field form to use the 3-field form and deletes the compatibility code. test/Verifier/global-ctors-2.ll checks we have a friendly error message. For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the 2-field form (add i8* null as the third field). Reviewed By: rnk, dexonsmith Differential Revision: https://reviews.llvm.org/D61547 llvm-svn: 360742 2019-04-17T17:38:09+00:00 Steven Wu stevenwu@apple.com 2019-04-17T17:38:09+00:00 urn:sha1:05a358cdcd55d1ee0a0d92383aa49489479c6362 Summary: Reapply r357931 with fixes to ThinLTO testcases and llvm-lto tool. ThinLTOCodeGenerator currently does not preserve llvm.used symbols and it can internalize them. In order to pass the necessary information to the legacy ThinLTOCodeGenerator, the input to the code generator is rewritten to be based on lto::InputFile. Now ThinLTO using the legacy LTO API will requires data layout in Module. "internalize" thinlto action in llvm-lto is updated to run both "promote" and "internalize" with the same configuration as ThinLTOCodeGenerator. The old "promote" + "internalize" option does not produce the same output as ThinLTOCodeGenerator. This fixes: PR41236 rdar://problem/49293439 Reviewers: tejohnson, pcc, kromanova, dexonsmith Reviewed By: tejohnson Subscribers: ormris, bd1976llvm, mehdi_amini, inglorion, eraman, hiraditya, jkorous, dexonsmith, arphaman, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60421 llvm-svn: 358601 2019-04-17T04:52:47+00:00 Eric Christopher echristo@gmail.com 2019-04-17T04:52:47+00:00 urn:sha1:cee313d288a4faf0355d76fb6e0e927e211d08a5 The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552 2019-04-17T02:12:23+00:00 Eric Christopher echristo@gmail.com 2019-04-17T02:12:23+00:00 urn:sha1:a86343512845c9c1fdbac865fea88aa5fce7142a As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546 2019-01-11T18:31:57+00:00 Teresa Johnson tejohnson@google.com 2019-01-11T18:31:57+00:00 urn:sha1:290a8398917a3d4ef521a0cfdb67e65238f0043a Summary: Records in the module summary index whether the bitcode was compiled with the option necessary to enable splitting the LTO unit (e.g. -fsanitize=cfi, -fwhole-program-vtables, or -fsplit-lto-unit). The information is passed down to the ModuleSummaryIndex builder via a new module flag "EnableSplitLTOUnit", which is propagated onto a flag on the summary index. This is then used during the LTO link to check whether all linked summaries were built with the same value of this flag. If not, an error is issued when we detect a situation requiring whole program visibility of the class hierarchy. This is the case when both of the following conditions are met: 1) We are performing LowerTypeTests or Whole Program Devirtualization. 2) There are type tests or type checked loads in the code. Note I have also changed the ThinLTOBitcodeWriter to also gate the module splitting on the value of this flag. Reviewers: pcc Subscribers: ormris, mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53890 llvm-svn: 350948 2018-06-01T15:20:47+00:00 Vlad Tsyrklevich vlad@tsyrklevich.net 2018-06-01T15:20:47+00:00 urn:sha1:6867ab7c908d70178fd6cb8bfed195fb176cf1a4 Summary: Emit summaries for bitcode modules that are only destined for the regular LTO portion of the build so they can participate in summary-based dead stripping. This change reduces the size of a nacl_helper build with cfi-icall enabled by 7%, removing the majority of the overhead due to enabling cfi-icall. The cfi-icall size increase was caused by compiling in lots of unused code and cfi-icall generating jumptable references to unused symbols that could no longer be removed by -Wl,-gc-sections. Increasing the visibility of summary-based dead stripping prevented jumptable entries being created for unused symbols from the regular LTO portion of the build. Reviewers: pcc Reviewed By: pcc Subscribers: dschuff, mehdi_amini, inglorion, eraman, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D47594 llvm-svn: 333768 2018-04-20T02:26:12+00:00 Vlad Tsyrklevich vlad@tsyrklevich.net 2018-04-20T02:26:12+00:00 urn:sha1:5d15230c37d2d9c5aa76b48003b34fe1dd12abc9 llvm-svn: 330388