The maximal virtual address on NetBSD/amd64 is 0x7f7ffffff000.
Define shadow offset 0x400000000000 (1ULL << 46).
Sponsored by <The NetBSD Foundation>
Differential D36587
Add NetBSD ASAN shadow mapping for x86-64 krytarowski on Aug 10 2017, 12:33 PM. Authored by
Details The maximal virtual address on NetBSD/amd64 is 0x7f7ffffff000. Sponsored by <The NetBSD Foundation>
Diff Detail
Event TimelineComment Actions I don't really get why the shadow offset differs between systems, I copied it from FreeBSD. Also there is a problem with X86 (32-bit). There are two possible options: 32-bit application on 32-bit kernel or on 64-bit kernel. For 32-bit kernel the maximal user address: What would be the proper offset here? Comment Actions I kindly ask for explanation of this shadow offset value. (My questions were on top, I see them hidden by Phabricator now) But anyway, I will commit it now and keep it optimizing in future. Comment Actions It's just an address where a shadow-sized hole is most like to be found. Comment Actions MAP_32BIT is Linux/FreeBSD specific, it's absent in NetBSD... does it mean that the shadowoffset should be 0? How about i386? For 32-bit kernel the maximal user address: Comment Actions NetBSD supports PIE and non-PIE executables. The non-PIE ones are the default option on x86_64. I'm going to execute tests with shadow at 0. While there waiting for build.. is PIE required for tsan? If so, why? https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/rtl/tsan_platform_posix.cc#L34 I need also enlightening how to translate struct Mapping to NetBSD https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/rtl/tsan_platform_posix.cc#L119 Comment Actions I'm not sure if that is the real reason, but TSan shadow is 8-to-1. It's hard to find an address that can fit such a big allocation in both PIE and non-PIE layout. Comment Actions Unless I'm looking wrongly Clang in SanitizerArgs.cpp, does not mandate PIE for TSAN. What determined the defined Linux/FreeBSD struct Mapping? I will follow it analogously with NetBSD specific bits like MAP_32BIT not needed. Comment Actions Looking at the comment, ^ these are the OS constraints, the rest can be moved. Another constraint is MemToShadowImpl() which, for any address in, I assume, writable memory (so any of the above + heap) needs to provide an distinct address in "shadow". AFAIK, "metainfo" and "traces" are completely arbitrary. Comment Actions I've checked that ShadowOffset 0 breaks ASAN. I'm having now trouble to translate these values to NetBSD.
Another thread: If I understand correctly there is an assumption that PIE code is mapped on Linux/FreeBSD into adjacent memory regions. This is not true on NetBSD (@joerg can correct me). I was trying to reuse Linux/FreeBSD process memory mapping and all tests fail. It breaks at PIE detection (I disabled it locally to check what happens). Comment Actions After turning off PIE verification (Linux/FreeBSD specific?), I was getting random corruption and SIGSEGV. |