[PATCH] D46456: [asan] Add support for Myriad RTEMS memory map

Vitaly Buka via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 17 11:42:38 PDT 2018


vitalybuka added inline comments.


================
Comment at: compiler-rt/lib/asan/asan_mapping.h:307
+  return SANITIZER_MYRIAD2 ? (a & ~kMyriadCacheBitMask32) : a;
+}
+
----------------
alekseyshl wrote:
> It would be more in the spirit of this file to define a macro here:
> #define RAW_ADDR(mem) (mem)
> and in asan_mapping_myriad.h:
> #define RAW_ADDR(mem) (mem & ~kMyriadCacheBitMask32)
The rest of the function is trivial, so not much value in code reuse.
Maybe just move what ever is using RAW_ADDR into myriad file?


================
Comment at: compiler-rt/lib/asan/asan_mapping_myriad.h:26
+
+#define kHighMemBeg    (kMyriadMemoryEnd32 + 1)
+
----------------
waltl wrote:
> waltl wrote:
> > alekseyshl wrote:
> > > If you do not have a concept of high mem, why not set kHighMemBeg and kHighMemEnd to 0? It'll make other conditions more explicit.
> > That's what I did originally.  Vitally suggested that I define things this way.  I'm fine with either.  The tradeoffs I see are:
> > 
> > - define as 0: cleaner conceptually, consistent with handling of mid memory.
> > 
> > - define as range [begin, begin - 1]: fewer changes required.
> > 
> I went back to setting kHighMemBeg to 0.
> 
It's not just fewer changes, with [begin, begin - 1] you don't need sentinel value like 0.  This also confusing because kLowMemBeg is 0 and it's not sentinel in that case.
Still we already use 0 as sentinel for kMidMemBeg.

So I'd prefer to convert all code into [begin, begin - 1] for unavailable regions, but feel free to keep as 0, as it's already a mix of approaches.



Repository:
  rL LLVM

https://reviews.llvm.org/D46456





More information about the llvm-commits mailing list