search for: kallocatorspace

Jakub makes a good point, are you sure that there is no single shadow offset value that works for all VMA variants? What exactly breaks when 1<<36 is used on 42-bit VMA? On Fri, Sep 25, 2015 at 3:28 AM, Yury Gribov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 09/25/2015 01:27 PM, Yury Gribov wrote: >> >> On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev

It would appear that the fix for https://bugs.llvm.org/show_bug.cgi?id=24155 really only applies to X86. Which I suppose is fine since that's where the bug was reported. However, we've recently upgraded the OS's on some of our PPC64 systems and are hitting the same problems. I certainly wouldn't mind providing a similar fix for PPC, but I don't know what the values in

..._MMAP_RANGE_SIZE, sizeof(Metadata), + SizeClassMap, kRegionSizeLog, ByteMap, + MsanMapUnmapCallback> PrimaryAllocator; #elif defined(__x86_64__) #if SANITIZER_LINUX && !defined(MSAN_LINUX_X86_64_OLD_MAPPING) static const uptr kAllocatorSpace = 0x700000000000ULL; - lib/msan/msan_linux.cc: diff --git a/lib/msan/msan_linux.cc b/lib/msan/msan_linux.cc index d6a9588..ca59564 100644 --- a/lib/msan/msan_linux.cc +++ b/lib/msan/msan_linux.cc @@ -82,7 +82,7 @@ static void CheckMemoryLayoutSanity() { CHECK_LT(start, end); CH...

...that would show that at least > those two settings work, the question is if 48-bit VMA (or how many) works > too, and if it does, the next thing is tweaking the library so that it can > perhaps with some small but still acceptable performance hit decide between > those at runtime (e.g. kAllocatorSpace/kAllocatorSize could be turned into > non-const variables for aarch64, harder would be to add some allocator that > at runtime picks if it uses 32-bit or 64-bit allocator. Hi Jakub, My assumption is based on what I understood from my talks with various people in sanitizers, libraries, GCC,...