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.
Ciao,
Michael.
