On 10/29/18 10:26, Michael Matz wrote:
Hi,
On Mon, 29 Oct 2018, Bill Seurer wrote:
Just for the record: am I right that any system using 44 bit of VMA will
fail because
anything + (1 << 44) will be out of process address space?
Yes.
And I noticed that documentation in sanitizer_linux.cc is misleading:
...
uptr GetMaxVirtualAddress() {
#if (SANITIZER_NETBSD || SANITIZER_OPENBSD) && defined(__x86_64__)
return 0x7f7ffffff000ULL; // (0x00007f8000000000 - PAGE_SIZE)
#elif SANITIZER_WORDSIZE == 64
# if defined(__powerpc64__) || defined(__aarch64__)
// On PowerPC64 we have two different address space layouts: 44- and
46-bit.
// We somehow need to figure out which one we are using now and choose
// one of 0x00000fffffffffffUL and 0x00003fffffffffffUL.
...
That should be adjusted.
Apparently for ppc64 there are many different layouts now, 44, 46, 47, 49,
52
at least depending on which kernel and page size you choose.
So, ideally we want some choice that works with all of them. Shadow offset
1ULL<<44 is not that choice.
We (llvm team) tried to get it to work on all the different kernels but didn't
find anything that worked. Finally we just went with a value that worked on
the newer kernels as the 44 bit one was not a target of concern.
I'm still wondering what didn't work with 41 bits? AFAICS, due to
highshadow=highmem-offset and lowshadow=low+offset, and the existence of a
non-empty shadow-gap, offset must be minimum(vbits)-3 (vbits being one of
the above numbers). Why would 41 not work for the other vbit setting?
It would lead to a large shadow gap, but so? If a shadow-gap isn't
necessary then minimum(vbits)-2 would also work.
41 was what the value previously was and it did not work (IIRC with 47
bit VMA kernels which were "new" at the time) thus the change.
If someone comes up with something that they think will work I am
willing to test it with both llvm and gcc.
--
-Bill Seurer
