build: Add options to select sanitizers in configure.py #2437
Conversation
|
@tchaikov please review |
CMakeLists.txt
Outdated
| DEFAULT_BUILD_TYPES "Debug" "Sanitize" | ||
| CONDITION sanitizers_enabled) | ||
|
|
||
| if (sanitizers_enabled) |
There was a problem hiding this comment.
this does not work when we build seastar with a multi-config generator. in that case, the value of sanitizers_enabled would be a generator expression, which always evaluates to TRUE. and its value is supposed to be used like:
target_link_libraries (seastar
PUBLIC
$<${condition}:Sanitizers::address>)
CMakeLists.txt
Outdated
|
|
||
| if (sanitizers_enabled) | ||
| if ((NOT Seastar_SANITIZERS) OR (Seastar_SANITIZERS STREQUAL "")) | ||
| set (Seastar_SANITIZERS ${Seastar_DEFAULT_SANITIZERS}) |
There was a problem hiding this comment.
i'd suggest making Seastar_SANITIZERS a CMake option explicitly, like:
set (Seastar_SANITIZERS
"address;undefined_behavior"
CACHE
STRING
"Sanitizers enabled when building Seastar")and if we build with multi-config generator, this option applies to Debug and Sanitize modes, otherwise, this option applies the the current build.
what do you think?
There was a problem hiding this comment.
I agree about multi-config generator.
It doesn't make sense to use sanitizers in other modes because they (at least address and thread) won't work with seastar allocator. But you still can do it by passing Seastar_SANITIZE=yes.
I can force to use sanitizers in ./configure.py if they are specified manually and args.mode != 'all'. What do you think?
P.S. ./configure.py does not use multi-config generator
There was a problem hiding this comment.
Now I left the logic of sanitizers and build modes unchanged. Enabling sanitizers depends on Seastar_SANITIZE variable. By default it enables them only for Debug and Sanitize
configure.py
Outdated
| @@ -171,15 +173,23 @@ def identify_best_standard(cpp_standards, compiler): | |||
|
|
|||
| MODE_TO_CMAKE_BUILD_TYPE = {'release': 'RelWithDebInfo', 'debug': 'Debug', 'dev': 'Dev', 'sanitize': 'Sanitize' } | |||
|
|
|||
| SANITIZER_TO_CMAKE = {'address': 'address', 'undefined': 'undefined_behavior'} | |||
There was a problem hiding this comment.
why not just use undefined_behavior? what's the merit of introducing another layer?
There was a problem hiding this comment.
Agree, the same thing happens in FindSanitizers.cmake. I deleted it
devDDen
force-pushed
the
select-sanitizers-in-configure-py
branch
from
798bd72
to
2d840e0
Compare
We are going to add ThreadSanitizer that can't be used together with AddressSanitizer. We want to choose which sanitizers to use. There are options to use sanitizers: Use ASAN and UBSAN for Debug and Sanitize build types: ./configure.py Use specified sanitizers for Debug and Sanitize build types: ./configure.py --sanitizer address --sanitizer undefined_behavior Do not use sanitizers for any build type: ./configure.py --no-sanitizers Enabling sanitizers is consistently with Seastar_SANITIZE option. Specified sanitizers are passed to Seastar_SANITIZERS list.
devDDen
force-pushed
the
select-sanitizers-in-configure-py
branch
from
2d840e0
to
7305f93
Compare
We are going to add ThreadSanitizer that can't be used together with AddressSanitizer. We want to choose which sanitizers to use.
There are options to use sanitizers:
Use ASAN and UBSAN for Debug and Sanitize build types:
Use specified sanitizers for Debug and Sanitize build types:
Do not use sanitizers for any build type:
Enabling sanitizers is consistently with Seastar_SANITIZE option.
Specified sanitizers are passed to
Seastar_SANITIZERSlist.