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