2017-12-09 09:31:51 +08:00
|
|
|
# -*- Python -*-
|
|
|
|
|
|
|
|
|
|
import os
|
|
|
|
|
|
|
|
|
|
# Setup config name.
|
|
|
|
|
config.name = 'HWAddressSanitizer' + getattr(config, 'name_suffix', 'default')
|
|
|
|
|
|
|
|
|
|
# Setup source root.
|
|
|
|
|
config.test_source_root = os.path.dirname(__file__)
|
|
|
|
|
|
|
|
|
|
# Setup default compiler flags used with -fsanitize=memory option.
|
hwasan: Use system allocator to realloc and free untagged pointers in interceptor mode.
The Android dynamic loader has a non-standard feature that allows
libraries such as the hwasan runtime to interpose symbols even after
the symbol already has a value. The new value of the symbol is used to
relocate libraries loaded after the interposing library, but existing
libraries keep the old value. This behaviour is activated by the
DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to
the linker, which is what we already do to link the hwasan runtime.
What this means in practice is that if we have .so files that depend
on interceptor-mode hwasan without the main executable depending on
it, some of the libraries in the process will be using the hwasan
allocator and some will be using the system allocator, and these
allocators need to interact somehow. For example, if an instrumented
library calls a function such as strdup that allocates memory on
behalf of the caller, the instrumented library can reasonably expect
to be able to call free to deallocate the memory.
We can handle that relatively easily with hwasan by using tag 0 to
represent allocations from the system allocator. If hwasan's realloc
or free functions are passed a pointer with tag 0, the system allocator
is called.
One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.
Differential Revision: https://reviews.llvm.org/D55986
llvm-svn: 350427
2019-01-05 03:21:51 +08:00
|
|
|
clang_cflags = [config.target_cflags] + config.debug_info_flags
|
|
|
|
|
clang_cxxflags = config.cxx_mode_flags + clang_cflags
|
2019-06-18 07:39:51 +08:00
|
|
|
clang_hwasan_cflags = ["-fsanitize=hwaddress"] + clang_cflags
|
2017-12-09 09:31:51 +08:00
|
|
|
clang_hwasan_cxxflags = config.cxx_mode_flags + clang_hwasan_cflags
|
|
|
|
|
|
|
|
|
|
def build_invocation(compile_flags):
|
|
|
|
|
return " " + " ".join([config.clang] + compile_flags) + " "
|
|
|
|
|
|
hwasan: Use system allocator to realloc and free untagged pointers in interceptor mode.
The Android dynamic loader has a non-standard feature that allows
libraries such as the hwasan runtime to interpose symbols even after
the symbol already has a value. The new value of the symbol is used to
relocate libraries loaded after the interposing library, but existing
libraries keep the old value. This behaviour is activated by the
DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to
the linker, which is what we already do to link the hwasan runtime.
What this means in practice is that if we have .so files that depend
on interceptor-mode hwasan without the main executable depending on
it, some of the libraries in the process will be using the hwasan
allocator and some will be using the system allocator, and these
allocators need to interact somehow. For example, if an instrumented
library calls a function such as strdup that allocates memory on
behalf of the caller, the instrumented library can reasonably expect
to be able to call free to deallocate the memory.
We can handle that relatively easily with hwasan by using tag 0 to
represent allocations from the system allocator. If hwasan's realloc
or free functions are passed a pointer with tag 0, the system allocator
is called.
One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.
Differential Revision: https://reviews.llvm.org/D55986
llvm-svn: 350427
2019-01-05 03:21:51 +08:00
|
|
|
config.substitutions.append( ("%clangxx ", build_invocation(clang_cxxflags)) )
|
2017-12-09 09:31:51 +08:00
|
|
|
config.substitutions.append( ("%clang_hwasan ", build_invocation(clang_hwasan_cflags)) )
|
|
|
|
|
config.substitutions.append( ("%clangxx_hwasan ", build_invocation(clang_hwasan_cxxflags)) )
|
hwasan: Use system allocator to realloc and free untagged pointers in interceptor mode.
The Android dynamic loader has a non-standard feature that allows
libraries such as the hwasan runtime to interpose symbols even after
the symbol already has a value. The new value of the symbol is used to
relocate libraries loaded after the interposing library, but existing
libraries keep the old value. This behaviour is activated by the
DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to
the linker, which is what we already do to link the hwasan runtime.
What this means in practice is that if we have .so files that depend
on interceptor-mode hwasan without the main executable depending on
it, some of the libraries in the process will be using the hwasan
allocator and some will be using the system allocator, and these
allocators need to interact somehow. For example, if an instrumented
library calls a function such as strdup that allocates memory on
behalf of the caller, the instrumented library can reasonably expect
to be able to call free to deallocate the memory.
We can handle that relatively easily with hwasan by using tag 0 to
represent allocations from the system allocator. If hwasan's realloc
or free functions are passed a pointer with tag 0, the system allocator
is called.
One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.
Differential Revision: https://reviews.llvm.org/D55986
llvm-svn: 350427
2019-01-05 03:21:51 +08:00
|
|
|
config.substitutions.append( ("%compiler_rt_libdir", config.compiler_rt_libdir) )
|
2017-12-09 09:31:51 +08:00
|
|
|
|
2018-01-11 03:36:10 +08:00
|
|
|
default_hwasan_opts_str = ':'.join(['disable_allocator_tagging=1', 'random_tags=0'] + config.default_sanitizer_opts)
|
2017-12-09 09:31:51 +08:00
|
|
|
if default_hwasan_opts_str:
|
|
|
|
|
config.environment['HWASAN_OPTIONS'] = default_hwasan_opts_str
|
|
|
|
|
default_hwasan_opts_str += ':'
|
|
|
|
|
config.substitutions.append(('%env_hwasan_opts=',
|
|
|
|
|
'env HWASAN_OPTIONS=' + default_hwasan_opts_str))
|
|
|
|
|
|
|
|
|
|
# Default test suffixes.
|
|
|
|
|
config.suffixes = ['.c', '.cc', '.cpp']
|
|
|
|
|
|
|
|
|
|
if config.host_os not in ['Linux', 'Android']:
|
|
|
|
|
config.unsupported = True
|