Posted draft commit in http://llvm-reviews.chandlerc.com/D3119

64-bit app on x86_64 machine:
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem     ||

32-bit app on x86_64 machine:
|| `[0x40000000, 0xffffffff]` || HighMem    ||
|| `[0x28000000, 0x3fffffff]` || HighShadow ||
|| `[0x24000000, 0x27ffffff]` || ShadowGap  ||
|| `[0x20000000, 0x23ffffff]` || LowShadow  ||
|| `[0x00000000, 0x1fffffff]` || LowMem     ||

32-bit app on i686 machine:
|| `[0x38000000, 0xbfffffff]` || HighMem    ||
|| `[0x27000000, 0x37ffffff]` || HighShadow ||
|| `[0x24000000, 0x26ffffff]` || ShadowGap  ||
|| `[0x20000000, 0x23ffffff]` || LowShadow  ||
|| `[0x00000000, 0x1fffffff]` || LowMem     ||

check-asan and check-sanitizer tests passed (apart from non-portable tests).

should be fixed by http://llvm.org/viewvc/llvm-project?rev=204897&view=rev

fix reverted in http://llvm.org/viewvc/llvm-project?rev=207768&view=rev

Ok, how about this - try mapping 1 page in the middle of high Gb and see if resulting
addresss managed to get there.

Another option would be to scan /proc/PID/maps for read-write regions in high addresses
but this sounds somewhat less robust...

We can try 
  1. checking /proc/PID/maps
  2. mmapping several addresses in the upper 1Gb
  3. checking where is the current stack pointer

None of that is exceptionally robust (although #3 should work on most systems I've
encountered). 
Maybe also hide this feature under a flag?

I'd say mmaping the last page in address space and checking the output sounds pretty
robust. I'm ok with flag though.

>> mmaping the last page
This is a subset of #2

Why do you suggest several mappings btw? AFAIK mmap will try to map the closest page
to the requested one.

ah, you suggest to use a hint, not MAP_FIXED. 
May work. Especially if you hide it under a flag :) 

Ok, I'll send a patch then. As for flags - as I said I personally have no problem with
them but this feature looks really important. Perhaps we could enable it by default
when it's proven stable?

We can have it under a flag which is *on* by default,
but it's important to be able to disable it if it goes wrong somewhere

Ok, mmap trick didn't work for (it looks like kernel does not respect address hint deeply
enough). All other tricks are rather unstable as well.

I think the core problem with schroot is that it sets non-trivial personality. We should
be able to detect this (by checking return value of personality(-1)) and leave default
4G limit unchanged.

Done in r204897 and r208760.

Adding Project:AddressSanitizer as part of GitHub migration.