| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[Sw64] Add Sw64 target support for compiler-rt | 1 年前 | |
[asan][test] Fix typo in Unit/lit.site.cfg.py.in I noticed that test/asan/Unit/lit.site.cfg.py.in contains two typos, using the FreeBSD forms of the LD_*LIBRARY_PATH* variables on Solaris. Tested on amd64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D132736 | 3 年前 | |
[Sw64] Add Sw64 target support for compiler-rt | 1 年前 | |
sanitizer_common: initialize sanitizer runtimes lazily from signal interceptors Currently if a program calls sigaction very early (before non-lazy sanitizer initialization, in particular if .preinit_array initialization is not enabled), then sigaction will wrongly fail since the interceptor is not initialized yet. In all other interceptors we do lazy runtime initialization for this reason, but we don't do it in the signal interceptors. Do lazy runtime initialization in signal interceptors as well. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D155188 | 2 年前 | |
[sanitizer] Disable fast_unwind_on_malloc as default for arm-linux-gnu ARM thumb/thumb2 frame pointer is inconsistent on GCC and Clang [1] and fast-unwider is also unreliable when mixing arm and thumb code [2]. The fast unwinder on ARM tries to probe and compare the frame-pointer at different stack layout positions and it works reliable only on systems where all the libraries were built in arm mode (either with gcc or clang) or with clang in thmb mode (which uses the same stack frame pointer layout in arm and thumb). However when mixing objects built with different abi modes the fast unwinder is still problematic as shown by the failures on the AddressSanitizer.ThreadStackReuseTest. For these failures, the malloc is called by the loader itself and since it has been built with a thum enabled gcc, the stack frame is not correctly obtained and the suppression rule is not applied (resulting in a leak warning). The check for fast-unwinder-works is also changed: instead of checking f it is explicit enabled in the compiler flags, it now checks if compiler defined thumb pre-processor. This should fix BZ#44158. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172 [2] https://bugs.llvm.org/show_bug.cgi?id=44158 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D88958 | 5 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 5 年前 |