The function works like MapDynamicShadow, except that it creates aliased
memory to the right of the shadow. The main use case is for HWASan
aliasing mode, which gets fast IsAlias() checks by exploiting the fact
that the upper bits of the shadow base and aliased memory match.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp | ||
---|---|---|
923 | This should be internal_mremap, in case mremap in libc is instrumented. |
LGTM
compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp | ||
---|---|---|
188 ↗ | (On Diff #329779) | I do not think this check is necessary. You can simply pass all the argument to the kernel. |
compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp | ||
---|---|---|
958 | Maybe :) |
- Simplify and improve readability.
compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp | ||
---|---|---|
958 | I think it is less readable, though doing ~0 is also not super clear. I've changed it to cast -1 to uptr, since this is what mmap(2) says MAP_FAILED is. |
This patch broke the Solaris buildbots (Solaris/sparcv9 and Solaris/amd64:
FAILED: projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.i386.dir/sanitizer_linux_libcdep.cpp.o [...] /vol/llvm/src/llvm-project/dist/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp: In function ‘__sanitizer::uptr __sanitizer::MremapCreateAlias(__sanitizer::uptr, __sanitizer::uptr, __sanitizer::uptr)’: /vol/llvm/src/llvm-project/dist/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:928:26: error: ‘MREMAP_MAYMOVE’ was not declared in this scope 928 | MREMAP_MAYMOVE | MREMAP_FIXED, | ^~~~~~~~~~~~~~ /vol/llvm/src/llvm-project/dist/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:928:43: error: ‘MREMAP_FIXED’ was not declared in this scope; did you mean ‘MAP_FIXED’? 928 | MREMAP_MAYMOVE | MREMAP_FIXED, | ^~~~~~~~~~~~ | MAP_FIXED
Despite its name, sanitizer_linux_libcdep.cpp is shared between FreeBSD, Linux, NetBSD, and Solaris, while according to the Linux manpage, mremap is Linux-only.
That's confusing... I've submitted https://github.com/llvm/llvm-project/commit/643d87ebab7882442400fbb983f2b6a268012b50 to fix the build.
Indeed. However, the misleading filenames are just the tip of the iceberg. Hardcoding every feature check with platform macros instead of feature tests (preferably detected at build time) feels so 90ies...
Once I'd pulled in an unrelated fix for another unrelated build-breaking bug, the bots are back to normal. Thanks!
This should be internal_mremap, in case mremap in libc is instrumented.