Yea, this prelink thing is very confusing. better just not use it when running asan -- I don't know if anyone is continuously testing that asan works with prelink.
And yes, this is not a big deal. --kcc On Fri, Nov 4, 2016 at 3:10 PM, Kuba Brecka <[email protected]> wrote: > Hi, > > I've been asked about this at the LLVM Dev Meeting by Eric Feng: The ASan > memory mapping for Linux with prelink looks like this (taken from > asan_mapping.h): > > // || `[0x10007fff8000, 0x7fffffffffff]` || HighMem || > // || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || > // || `[0x005000000000, 0x02008fff6fff]` || ShadowGap3 || > // || `[0x003000000000, 0x004fffffffff]` || MidMem || > // || `[0x000a7fff8000, 0x002fffffffff]` || ShadowGap2 || > // || `[0x00067fff8000, 0x000a7fff7fff]` || MidShadow || > // || `[0x00008fff7000, 0x00067fff7fff]` || ShadowGap || > // || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow || > // || `[0x000000000000, 0x00007fff7fff]` || LowMem || > > There seems to be a part of HighShadow where the mapping doesn't point to > any of the ShadowGaps, but instead it points to MidMem. E.g. > MEM_TO_SHADOW(0x02008fff7000) > == 0x004091ff6e00). While this may not be a big deal, I'm just wondering > if that's intentional. If yes, this should be documented as a comment in > asan_mapping.h. This seems to have been done in r176250 without mentioning > that a part of the shadow memory is not covered by a shadow gap anymore. > > Thanks, > Kuba > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
