Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0 |
|
#
d8626c30 |
| 15-Sep-2023 |
nicole mazzuca <nicole@strega-nil.co> |
[sanitizer_common] Add internal_wcs[n]cpy functions (#66529)
These functions are required for the related wcs[n]cpy functions to be
wrapped on Windows, since given our current method of wrapping
f
[sanitizer_common] Add internal_wcs[n]cpy functions (#66529)
These functions are required for the related wcs[n]cpy functions to be
wrapped on Windows, since given our current method of wrapping
functions, calling REAL(wcs[n]cpy) is broken.
@vitalybuka requested that these changes be split out from
llvm/llvm-project#66128.
show more ...
|
Revision tags: llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
0a71e25e |
| 30-May-2023 |
Marco Elver <elver@google.com> |
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack ar
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack arrays, as shown by the new tests added for asan and msan (tsan already had this test).
In general, the problem of compiler-inserted memintrinsic calls (memset/memcpy/memmove) is not new to compiler-rt, and has been a problem before.
To avoid introducing unwanted memintrinsic calls, we redefine memintrinsics as __sanitizer_internal_mem* at the assembly level for most source files automatically (where sanitizer_common_internal_defs.h is included).
In few cases, redefining a symbol in this way causes issues for interceptors, namely the memintrinsic interceptor themselves. For such source files we have to selectively disable the redefinition.
Other alternatives have been considered, but simply do not work well in the context of compiler-rt:
1. Linker --wrap: this does not work because --wrap only applies to the final link, and would not apply when building sanitizer static libraries.
2. Changing references to memset() via objcopy: this may work, but due to the complexities of the build system, introducing such a post-processing step for the right object files (in particular object files defining memset cannot be touched) seems infeasible.
The chosen solution works well (as shown by the tests). Other libraries have chosen the same solution where nothing else works (see e.g. glibc's "symbol-hacks.h").
v4: - Add interface attribute to __sanitizer_internal_mem* declarations as well, as otherwise some compilers (MSVC) will complain. - Add SANITIZER_COMMON_NO_REDEFINE_BUILTINS to source files using C++STL, since this could lead to ODR violations (see added comment).
v3: - Don't use ALIAS() to alias internal_mem*() functions to __sanitizer_internal_mem*() functions, but just define them as ALWAYS_INLINE functions instead. This will work on darwin and windows.
v2: - Fix ubsan_minimal build where compiler decides to insert memset/memcpy: ubsan_minimal has work without RTSanitizerCommonLibc, therefore do not redefine the builtins. - Fix definition of internal_mem* functions with compilers that want the aliased function to already be defined before. - Fix definition of __sanitizer_internal_mem* functions with compilers more pedantic about attribute placement around extern "C".
Reviewed By: vitalybuka, dvyukov
Differential Revision: https://reviews.llvm.org/D151152
show more ...
|
#
8e547948 |
| 02-Jun-2023 |
Marco Elver <elver@google.com> |
Revert "[compiler-rt] Avoid memintrinsic calls inserted by the compiler"
This reverts commit fc011a72881cdddc95bfa61f3f38916c29b7e362. This reverts commit 4ad6a0c9a409b19b950a6a2a90d5405cea2e9b89. T
Revert "[compiler-rt] Avoid memintrinsic calls inserted by the compiler"
This reverts commit fc011a72881cdddc95bfa61f3f38916c29b7e362. This reverts commit 4ad6a0c9a409b19b950a6a2a90d5405cea2e9b89. This reverts commit 4b1eb4cf0e8eff5f68410720167b4986da597010.
Still causes Windows build bots to fail.
show more ...
|
#
4b1eb4cf |
| 30-May-2023 |
Marco Elver <elver@google.com> |
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack ar
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack arrays, as shown by the new tests added for asan and msan (tsan already had this test).
In general, the problem of compiler-inserted memintrinsic calls (memset/memcpy/memmove) is not new to compiler-rt, and has been a problem before.
To avoid introducing unwanted memintrinsic calls, we redefine memintrinsics as __sanitizer_internal_mem* at the assembly level for most source files automatically (where sanitizer_common_internal_defs.h is included).
In few cases, redefining a symbol in this way causes issues for interceptors, namely the memintrinsic interceptor themselves. For such source files we have to selectively disable the redefinition.
Other alternatives have been considered, but simply do not work well in the context of compiler-rt:
1. Linker --wrap: this does not work because --wrap only applies to the final link, and would not apply when building sanitizer static libraries.
2. Changing references to memset() via objcopy: this may work, but due to the complexities of the build system, introducing such a post-processing step for the right object files (in particular object files defining memset cannot be touched) seems infeasible.
The chosen solution works well (as shown by the tests). Other libraries have chosen the same solution where nothing else works (see e.g. glibc's "symbol-hacks.h").
v3: - Don't use ALIAS() to alias internal_mem*() functions to __sanitizer_internal_mem*() functions, but just define them as ALWAYS_INLINE functions instead. This will work on darwin and windows.
v2: - Fix ubsan_minimal build where compiler decides to insert memset/memcpy: ubsan_minimal has work without RTSanitizerCommonLibc, therefore do not redefine the builtins. - Fix definition of internal_mem* functions with compilers that want the aliased function to already be defined before. - Fix definition of __sanitizer_internal_mem* functions with compilers more pedantic about attribute placement around extern "C".
Reviewed By: vitalybuka, dvyukov
Differential Revision: https://reviews.llvm.org/D151152
show more ...
|
#
8e728adc |
| 31-May-2023 |
Marco Elver <elver@google.com> |
Revert "[compiler-rt] Avoid memintrinsic calls inserted by the compiler"
This reverts commit 4369de7af46605522bf7dbe3bc31d00b0eb4bee6.
Fails on Mac OS with "sanitizer_libc.cpp:109:5: error: aliases
Revert "[compiler-rt] Avoid memintrinsic calls inserted by the compiler"
This reverts commit 4369de7af46605522bf7dbe3bc31d00b0eb4bee6.
Fails on Mac OS with "sanitizer_libc.cpp:109:5: error: aliases are not supported on darwin".
show more ...
|
#
4369de7a |
| 30-May-2023 |
Marco Elver <elver@google.com> |
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack ar
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack arrays, as shown by the new tests added for asan and msan (tsan already had this test).
In general, the problem of compiler-inserted memintrinsic calls (memset/memcpy/memmove) is not new to compiler-rt, and has been a problem before.
To avoid introducing unwanted memintrinsic calls, we redefine memintrinsics as __sanitizer_internal_mem* at the assembly level for most source files automatically (where sanitizer_common_internal_defs.h is included).
In few cases, redefining a symbol in this way causes issues for interceptors, namely the memintrinsic interceptor themselves. For such source files we have to selectively disable the redefinition.
Other alternatives have been considered, but simply do not work well in the context of compiler-rt:
1. Linker --wrap: this does not work because --wrap only applies to the final link, and would not apply when building sanitizer static libraries.
2. Changing references to memset() via objcopy: this may work, but due to the complexities of the build system, introducing such a post-processing step for the right object files (in particular object files defining memset cannot be touched) seems infeasible.
The chosen solution works well (as shown by the tests). Other libraries have chosen the same solution where nothing else works (see e.g. glibc's "symbol-hacks.h").
v2: - Fix ubsan_minimal build where compiler decides to insert memset/memcpy: ubsan_minimal has work without RTSanitizerCommonLibc, therefore do not redefine the builtins. - Fix definition of internal_mem* functions with compilers that want the aliased function to already be defined before. - Fix definition of __sanitizer_internal_mem* functions with compilers more pedantic about attribute placement around extern "C".
Reviewed By: vitalybuka, dvyukov
Differential Revision: https://reviews.llvm.org/D151152
show more ...
|
#
26bda9e9 |
| 31-May-2023 |
Marco Elver <elver@google.com> |
Revert "[compiler-rt] Avoid memintrinsic calls inserted by the compiler"
This reverts commit e614d5667f6c6fc6c645587cb9aee1a058285454.
Build bot failures:
| FAILED: lib/clang/17/lib/linux/libclang
Revert "[compiler-rt] Avoid memintrinsic calls inserted by the compiler"
This reverts commit e614d5667f6c6fc6c645587cb9aee1a058285454.
Build bot failures:
| FAILED: lib/clang/17/lib/linux/libclang_rt.ubsan_minimal-i386.so | : && /usr/bin/clang++ -fPIC -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -Wno-unused-parameter -O3 -DNDEBUG -Wl,-z,defs -Wl,-z,nodelete -m32 -nodefaultlibs -Wl,-z,text -nostdlib++ -shared -Wl,-soname,libclang_rt.ubsan_minimal-i386.so -o lib/clang/17/lib/linux/libclang_rt.ubsan_minimal-i386.so projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o -lgcc_s -lc && : | /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_type_mismatch_minimal': | /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:120: undefined reference to `__sanitizer_internal_memcpy' | /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_type_mismatch_minimal_abort': | /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:120: undefined reference to `__sanitizer_internal_memcpy' | /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_alignment_assumption_minimal': | /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:121: undefined reference to `__sanitizer_internal_memcpy' | /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_alignment_assumption_minimal_abort': | /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:121: undefined reference to `__sanitizer_internal_memcpy' | /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_add_overflow_minimal': | /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:122: undefined reference to `__sanitizer_internal_memcpy' | /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o:/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:122: more undefined references to `__sanitizer_internal_memcpy' follow
Link: https://lab.llvm.org/buildbot#builders/74/builds/19569
show more ...
|
#
e614d566 |
| 30-May-2023 |
Marco Elver <elver@google.com> |
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack ar
[compiler-rt] Avoid memintrinsic calls inserted by the compiler
D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack arrays, as shown by the new tests added for asan and msan (tsan already had this test).
In general, the problem of compiler-inserted memintrinsic calls (memset/memcpy/memmove) is not new to compiler-rt, and has been a problem before.
To avoid introducing unwanted memintrinsic calls, we redefine memintrinsics as __sanitizer_internal_mem* at the assembly level for most source files automatically (where sanitizer_common_internal_defs.h is included).
In few cases, redefining a symbol in this way causes issues for interceptors, namely the memintrinsic interceptor themselves. For such source files we have to selectively disable the redefinition.
Other alternatives have been considered, but simply do not work well in the context of compiler-rt:
1. Linker --wrap: this does not work because --wrap only applies to the final link, and would not apply when building sanitizer static libraries.
2. Changing references to memset() via objcopy: this may work, but due to the complexities of the build system, introducing such a post-processing step for the right object files (in particular object files defining memset cannot be touched) seems infeasible.
The chosen solution works well (as shown by the tests). Other libraries have chosen the same solution where nothing else works (see e.g. glibc's "symbol-hacks.h").
Reviewed By: vitalybuka, dvyukov
Differential Revision: https://reviews.llvm.org/D151152
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
6396a443 |
| 06-Jan-2022 |
Vitaly Buka <vitalybuka@google.com> |
Revert "SIGSEGV in Sanitizer INTERCEPTOR of strstr function."
Breaks Asan on Fuchsia's and ubsan with gcc.
This reverts commit 685c94c6cbba4f2bf076b01fd3e0dcb4b1425b53.
|
#
685c94c6 |
| 22-Dec-2021 |
Bharadwaj, Ritanya B <ritanya-b.bharadwaj@hpe.com> |
SIGSEGV in Sanitizer INTERCEPTOR of strstr function.
This is a segmentation fault in INTERCEPTOR function on a special edge case of strstr libc call. When 'Haystack'(main string to be examined) is N
SIGSEGV in Sanitizer INTERCEPTOR of strstr function.
This is a segmentation fault in INTERCEPTOR function on a special edge case of strstr libc call. When 'Haystack'(main string to be examined) is NULL and 'needle'(sub-string to be searched in 'Haystack') is an empty string then it hits a SEGV while using sanitizers and as a 'string not found' case otherwise.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D115919
show more ...
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
#
40067b88 |
| 18-Aug-2021 |
Michael Jones <michaelrj@google.com> |
[compiler-rt] change internal internal libc invariants
llvm-libc is expected to be built with sanitizers and not use interceptors in the long run. For now though, we have a hybrid process, where fun
[compiler-rt] change internal internal libc invariants
llvm-libc is expected to be built with sanitizers and not use interceptors in the long run. For now though, we have a hybrid process, where functions implemented in llvm-libc are instrumented, and glibc fills and sanitizer interceptors fill in the rest.
Current sanitizers have an invariant that the REAL(...) function called from inside of an interceptor is uninstrumented. A lot of interceptors call strlen() in order to figure out the size of the region to check/poison. Switch these callsites over to the internal, unsanitized implementation.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108316
show more ...
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5 |
|
#
d2af368a |
| 12-Sep-2019 |
Vitaly Buka <vitalybuka@google.com> |
[compiler-rt] Remove some cpplint filters
llvm-svn: 371704
|
Revision tags: llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2 |
|
#
65492d95 |
| 31-Jul-2019 |
Nico Weber <nicolasweber@gmx.de> |
compiler-rt: Rename .cc file in lib/sanitizer_common to .cpp
See https://reviews.llvm.org/D58620 for discussion, and for the commands I ran. In addition I also ran
for f in $(svn diff | diffstat
compiler-rt: Rename .cc file in lib/sanitizer_common to .cpp
See https://reviews.llvm.org/D58620 for discussion, and for the commands I ran. In addition I also ran
for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done
and manually updated (many) references to renamed files found by that.
llvm-svn: 367463
show more ...
|