Remove direct uses of Mapping in preperation for removing Mapping type
(which we already don't have for all platforms).
Remove dependence on HAS_48_BIT_ADDRESS_SPACE in preparation for removing it.
As far as I see for Apple/Mac platforms !HAS_48_BIT_ADDRESS_SPACE
simply means SANITIZER_IOS.
Depends on D107741.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107742
First, the define conflicts with definition/testing of all mappings,
since it's not a global property anymore. Second, macros/ifdefs are bad.
Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead.
Depends on D107736.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107737
The kernel supports a full 64-bit VMA, but we can use only 48 bits due
to the limitation imposed by SyncVar::GetId(). So define the address
ranges similar to the other architectures, except that the address
space "tail" needs to be made inaccessible in CheckAndProtect(). Since
it's for only one architecture, don't make an abstraction for this.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D105629
All check-tsan tests fail on aarch64-*-linux because HeapMemEnd() > ShadowBeg()
for the following code path:
```
#if defined(__aarch64__) && !HAS_48_BIT_ADDRESS_SPACE
ProtectRange(HeapMemEnd(), ShadowBeg());
```
Restore the behavior before D86377 for aarch64-*-linux.
This reverts commit bde2e56071.
This patch produces a compile failure on linux amd64 environments, when
running:
ninja GotsanRuntimeCheck
I get various build errors:
../rtl/tsan_platform.h:608: error: use of undeclared identifier 'Mapping'
return MappingImpl<Mapping, Type>();
Here's a buildbot with the same failure during stage "check-tsan in gcc
build", there are other unrelated failures in there.
http://lab.llvm.org:8011/#/builders/37/builds/2831
Disable huge pages in the TSan shadow regions when no_huge_pages_for_shadow == true (default).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D85841
in madvise mode, the shadow pages will be migrated only via madvise explicit calls.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D65775
llvm-svn: 368090
Dmitry Vyukov