[PATCH] [asan] [mips] added support of asan for mips64/mips64el

[Kostya Serebryany]

================
Comment at: lib/asan/asan_allocator.h:107
@@ -105,1 +106,3 @@
+const uptr kAllocatorSpace = 0x4000000000ULL;
+const uptr kAllocatorSize  = 0x4000000000ULL;  // 256GB.
 # else
----------------
dsanders wrote:
> kcc wrote:
> > Is this enough? 
> > As I've asked in http://reviews.llvm.org/D5906, did you verify that this works on
> > applications that allocate 8Gb of RAM with the same size class? 
> > Or mips machines are not expected to be used with that much RAM? 
> > What is the maximal amount of physical RAM in a mips machine for a foreseeable future? 
> > As I've asked in http://reviews.llvm.org/D5906, did you verify that this works on applications that allocate 8Gb of RAM with the same size class? 
> > Or mips machines are not expected to be used with that much RAM? 
> > What is the maximal amount of physical RAM in a mips machine for a foreseeable future?
> 
> I can't answer the 'Is this enough?' question but at the moment the biggest machines we have available to test on have 8GB RAM. It seems reasonable to predict that there will be >32GB machines in the not too distant future though.
> 
> One other thing to mention is that I've just found out that MIPS64r1 is limited to 36-bit physical addresses (64GB). MIPS64r2 added an extension to provide (up to) 59-bit physical addresses. On both architectures, there is a 64-bit virtual address space of which half is for the kernel and half is for user applications.
The way SanitizerAllocator64 is designed it will not work with 36-bit physical addresses. 
It will appear to work on small tests, but as soon as you try to allocate Gigs of RAM with e.g. 32-byte chunks it will run out of space.
So, for 36-bit space just use SanitizerAllocator32

59-bit physical addresses should be more than enough to use SanitizerAllocator64

http://reviews.llvm.org/D6024