From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: tarantool-patches@dev.tarantool.org, tsafin@tarantool.org
Subject: [Tarantool-patches] [PATCH 2/2] cmake: split UB sanitations into separate flags.
Date: Sun, 14 Jun 2020 18:24:31 +0200 [thread overview]
Message-ID: <c84614d839fe354963bbf11c2e6c83a5093f8e17.1592151487.git.v.shpilevoy@tarantool.org> (raw)
In-Reply-To: <cover.1592151487.git.v.shpilevoy@tarantool.org>
Clang undefined behaviour sanitizer was turned on using
-fsanitize=undefined flag, which is supposed to turn on all the
sanitizations, except a few ones. Not needed sanitations were
turned off explicitly, using -fno-sanitize=<type> flags. However
appeared it does not work with some flags. For example,
nullability sanitations can't be turned off when
-fsanitize=undefined is used.
Nullability sanitations lead to lots of false-positive fails
such as typeof(*obj) where obj is NULL, or memcpy() with NULL
destination but 0 size.
The patch splits -fsanitize=undefined into separate flags and
never turns on nullability checks.
Part of #4609
---
cmake/compiler.cmake | 44 ++++++++++++++++++++++++++++++++++++++++----
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/cmake/compiler.cmake b/cmake/compiler.cmake
index 6c0fa635c..6de8219a0 100644
--- a/cmake/compiler.cmake
+++ b/cmake/compiler.cmake
@@ -269,19 +269,55 @@ macro(enable_tnt_compile_flags)
if (NOT CMAKE_COMPILER_IS_CLANG)
message(FATAL_ERROR "Undefined behaviour sanitizer only available for clang")
else()
- set(SANITIZE_FLAGS "-fsanitize=undefined -fno-sanitize-recover=undefined")
+ string(JOIN "," SANITIZE_FLAGS
+ "alignment"
+ "bool"
+ "bounds"
+ "builtin"
+ "enum"
+ "float-cast-overflow"
+ "float-divide-by-zero"
+ "function"
+ "integer-divide-by-zero"
+ "return"
+ "shift"
+ "unreachable"
+ "vla-bound"
+ )
+
+ # Exclude "object-size".
+ # Gives compilation warnings when -O0 is used, which is always,
+ # because some tests build with -O0.
+
+ # Exclude "pointer-overflow".
# Stailq data structure subtracts a positive value from NULL.
- set(SANITIZE_FLAGS ${SANITIZE_FLAGS} -fno-sanitize=pointer-overflow)
+
+ # Exclude "vptr".
# Intrusive data structures may abuse '&obj->member' on pointer
# 'obj' which is not really a pointer at an object of its type.
# For example, rlist uses '&item->member' expression in macro cycles
# to check end of cycle, but on the last iteration 'item' points at
# the list metadata head, not at an object of type stored in this
# list.
- set(SANITIZE_FLAGS ${SANITIZE_FLAGS} -fno-sanitize=vptr)
+
+ # Exclude "implicit-signed-integer-truncation",
+ # "implicit-integer-sign-change", "signed-integer-overflow".
# Integer overflow and truncation are disabled due to extensive
# usage of this UB in SQL code to 'implement' some kind of int65_t.
- set(SANITIZE_FLAGS ${SANITIZE_FLAGS} -fno-sanitize=implicit-signed-integer-truncation -fno-sanitize=implicit-integer-sign-change -fno-sanitize=signed-integer-overflow)
+
+ # Exclude "null", "nonnull-attribute", "nullability-arg",
+ # "returns-nonnull-attribute", "nullability-assign",
+ # "nullability-return".
+ # NULL checking is disabled, because this is not a UB and raises
+ # lots of false-positive fails such as typeof(*obj) with
+ # obj == NULL, or memcpy() with NULL argument and 0 size. All
+ # nullability sanitations are disabled, because from the tests it
+ # seems they implicitly turn each other on, when one is used. For
+ # example, having "returns-nonnull-attribute" may lead to fail in
+ # the typeof(*obj) when obj is NULL, even though there is nothing
+ # related to return.
+
+ set(SANITIZE_FLAGS "-fsanitize=${SANITIZE_FLAGS} -fno-sanitize-recover=${SANITIZE_FLAGS}")
add_compile_flags("C;CXX" "${SANITIZE_FLAGS}")
endif()
--
2.21.1 (Apple Git-122.3)
next prev parent reply other threads:[~2020-06-14 16:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-14 16:24 [Tarantool-patches] [PATCH 0/2] ASAN build Vladislav Shpilevoy
2020-06-14 16:24 ` [Tarantool-patches] [PATCH 1/2] sql: don't build sql as a separate library Vladislav Shpilevoy
2020-06-15 15:42 ` Timur Safin
2020-06-14 16:24 ` Vladislav Shpilevoy [this message]
2020-06-15 15:41 ` [Tarantool-patches] [PATCH 2/2] cmake: split UB sanitations into separate flags Timur Safin
2020-06-15 22:19 ` Vladislav Shpilevoy
2020-06-15 14:01 ` [Tarantool-patches] [PATCH 0/2] ASAN build Alexander Turenko
2020-06-15 22:21 ` Vladislav Shpilevoy
2020-06-15 23:04 ` Alexander Turenko
2020-06-15 23:15 ` Vladislav Shpilevoy
2020-06-15 15:43 ` Timur Safin
2020-06-16 8:56 ` Kirill Yukhin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c84614d839fe354963bbf11c2e6c83a5093f8e17.1592151487.git.v.shpilevoy@tarantool.org \
--to=v.shpilevoy@tarantool.org \
--cc=tarantool-patches@dev.tarantool.org \
--cc=tsafin@tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH 2/2] cmake: split UB sanitations into separate flags.' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox