https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Ugh, there is also this junk: // By default we allow to use SizeClassAllocator64 on 64-bit platform. // But in some cases (e.g. AArch64's 39-bit address space) SizeClassAllocator64 // does not work well and we need to fallback to SizeClassAllocator32. // For such platforms build this code with -DSANITIZER_CAN_USE_ALLOCATOR64=0 or // change the definition of SANITIZER_CAN_USE_ALLOCATOR64 here. #ifndef SANITIZER_CAN_USE_ALLOCATOR64 # if defined(__aarch64__) || defined(__mips64) # define SANITIZER_CAN_USE_ALLOCATOR64 0 # else # define SANITIZER_CAN_USE_ALLOCATOR64 (SANITIZER_WORDSIZE == 64) # endif #endif It would be nice to know why that has been added. Was that just because #if SANITIZER_CAN_USE_ALLOCATOR64 # if defined(__powerpc64__) const uptr kAllocatorSpace = 0xa0000000000ULL; const uptr kAllocatorSize = 0x20000000000ULL; // 2T. # else const uptr kAllocatorSpace = 0x600000000000ULL; const uptr kAllocatorSize = 0x40000000000ULL; // 4T. # endif has not been adjusted for the port? What is the minimum kAllocatorSize that would work? Given the very small 39-bit VA option on aarch64, I think if the allocator64 memory has to be normal memory with shadow, we could only use say something like kAllocatorSpace 0x800000000 and kAllocatorSize the same value, i.e. 32GB. Would that be enough? There is also the: // The range of addresses which can be returned my mmap. // FIXME: this value should be different on different platforms, // e.g. on AArch64 it is most likely (1ULL << 39). Larger values will still work // but will consume more memory for TwoLevelByteMap. #if defined(__aarch64__) # define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL << 39) #else # define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL << 47) #endif which is again wrong for aarch64. Does it really has to be compile time constant? The 1ULL << 47 is also wrong ppc64, mips64, isn't it?
