These functions should not be externally used. We also do not need them internally for Fuchsia.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I don't think this is warranted. There should not be any references to such things when building for Fuchsia.
This looks like it's intended to satisfy one reference in dead code in hwasan_interceptors.cpp.
I think the right solution is just to refactor the hwasan code so that the dead code is not compiled for Fuchsia at all.
To add more context, this patch was meant to resolve this missing type error:
[27/32] Building CXX object compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj FAILED: compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj /usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-4-master-fuchsia-toolchain/./bin/clang++ --target=aarch64-unknown-fuchsia --sysroot=/usr/local/google/home/leonardchan/sdk/garnet/arch/arm64/sysroot -DHWASAN_REPLACE_OPERATORS_NEW_AND_DELETE=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/.. --target=aarch64-unknown-fuchsia -I/usr/local/google/home/leonardchan/sdk/garnet/pkg/fdio/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -ffunction-sections -fdata-sections -ffile-prefix-map=/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-4-master-fuchsia-toolchain/runtimes/runtimes-aarch64-unknown-fuchsia-bins=../llvm-build-4-master-fuchsia-toolchain/runtimes/runtimes-aarch64-unknown-fuchsia-bins -ffile-prefix-map=/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/= -no-canonical-prefixes -Wall -std=c++14 -Wno-unused-parameter -O2 -g -DNDEBUG -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -nostdinc++ -fno-rtti -fPIC -ffreestanding -ftls-model=initial-exec -MD -MT compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj -MF compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj.d -o compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj -c /usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan.cpp In file included from /usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan.cpp:14: In file included from /usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan.h:20: /usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan_interface_internal.h:204:11: error: no type named '__sanitizer_struct_mallinfo' in namespace '__hwasan' __hwasan::__sanitizer_struct_mallinfo __sanitizer_mallinfo(); ~~~~~~~~~~^
__sanitizer_struct_mallinfo is used as part of the hwasan interface:
SANITIZER_INTERFACE_ATTRIBUTE __hwasan::__sanitizer_struct_mallinfo __sanitizer_mallinfo();
So I'm thinking unless we want to change the API, we may not want to change or remove this function. The error comes up because __sanitizer_struct_mallinfo is currently only defined if SANITIZER_LINUX || SANITIZER_MAC is true, so it felt appropriate to add a fuchsia-specific definition in sanitizer_platform_limits_fuchsia.h which can just be empty if we don't use it anyway. Would refactoring still be applicable in this case?
*ping* @mcgrathr Given my explanation before, does it still make sense to refactor in this case?
compiler-rt/lib/hwasan/hwasan_interceptors.cpp | ||
---|---|---|
28 ↗ | (On Diff #333426) | we usually include them unconditionaly and .h itself has guards against unsupported platforms |
we usually include them unconditionaly and .h itself has guards against unsupported platforms
@vitalybuka Did you mean something like this? Definitely simplifies the patch.
What I think @vitalybuka meant is keeping sanitizer_platform_limits_fuchsia.h as you had it, but including it unconditionally. Since the entire file is wrapped in #if SANITIZER_FUCHSIA ... #endif, the inclusion would be a no-op on platforms other than Fuchsia so no need to wrap the #include in #if SANITIZER_FUCHSIA as well.
Correct., Just:
#include "sanitizer_common/sanitizer_platform_limits_fuchsia.h" #include "sanitizer_common/sanitizer_platform_limits_posix.h"
Frankly I don't think it makes sense to have __sanitizer_mallinfo and those other allocator functions declared in hwasan_interface_internal.h at all.
Those are neither APIs that the compiler emits nor ones that anyone else should use. They are just implementation details of the allocator interceptors.
I think a better cleanup is to move those declarations out of that file. I don't see why they need to be in any header file rather than just in hwasan_allocation_functions.cpp.
And if we don't need them in sanitizer/hwasan_interface.h and interface_internal,
why they need SANITIZER_INTERFACE_ATTRIBUTE
I can't find any callers other than compiler-rt/test/hwasan/TestCases/sanitizer_malloc.cpp
Could we remove these functions (including implementation)?
Thanks, it's preprocessor generated, so I can't find it :)
If so I guess LGTM.
But now they are in the same file, so instead of declarations, maybe just place SANITIZER_INTERFACE_ATTRIBUTE next to to the definition?
compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp | ||
---|---|---|
20 | isn't HWASAN_WITH_INTERCEPTORS enough? |
compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp | ||
---|---|---|
20 | Ignore this. !SANITIZER_FUCHSIA is OK here. |
Done. I'll take this as a review LGTM and submit tomorrow unless others have comments.
isn't HWASAN_WITH_INTERCEPTORS enough?