[PATCH] D13818: [compiler-rt] [msan] Unify aarch64 mapping

Evgeniy Stepanov via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 22 11:29:43 PDT 2015


eugenis added inline comments.

================
Comment at: lib/msan/msan.h:89
@@ -70,3 +88,3 @@
 # define LINEARIZE_MEM(mem) \
   (((uptr)(mem) & ~0x7C00000000ULL) ^ 0x100000000ULL)
 # define MEM_TO_SHADOW(mem) (LINEARIZE_MEM((mem)) + 0x4000000000ULL)
----------------
zatrazz wrote:
> eugenis wrote:
> > This is probably out of scope of this review, but could your elaborate, and maybe add a comment, about the constraints that led to this complex mapping function? For example, a list of all address ranges that must be in "app" regions would help.
> > 
> > This mapping limits the applications to roughly 1/7th of the address space on 39 bit VMA and only 1/30th on 42 bit VMA. Could we do any better?
> > 
> This is exactly what I am struggling with current aarch64 39 and 42-bit VMA contraints regarding PIE positioning. The memory segments are:
> 
> 0000000000-0010000000: both 39 and 42 for own programs segments
> 5500000000-5600000000: 39-bits PIE program segments
> 7f80000000-7000000000: 39-bits libraries segments
> 
> 2aa00000000-2ab00000000: 42-bits PIE program segments
> 3ff00000000-3ffffffffff: 42-bits libraries segments
> 
> I am trying to increase the segments size, but it is hard to come up with a single transformation that works on both 39 and 42-bit VMA that maps 39-bit to 39-bits and also works for 42-bits. I open to suggestions.
Can we do the same as on x86_64: flip either one or both of the most significant bits (38 & 37)?
39-bit addresses will stay 39-bit.
The following regions seem to have long enough constant left prefix for this transormation to be linear:
2aa00000000-2ab00000000: 42-bits PIE program segments
3ff00000000-3ffffffffff: 42-bits libraries segments

It will fragment 42-bit VMA in like 16 application segments, and the same number of shadow and origin; some of them will be marked invalid to avoid shadow/app/origin overlap with other segments. Not a problem, as long as the function is linear on any contiguous kernel-mapped range.



http://reviews.llvm.org/D13818





More information about the llvm-commits mailing list