<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, May 4, 2018 at 7:09 PM Walter Lee <<a href="mailto:waltl@google.com">waltl@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
<br>
> On RAM...<br>
<br>
> You chose the 32-byte shadow granularity to reduce the RAM overhead,<br>
> but I am afraid this will actually increase it due to extra alignment<br>
requirements,<br>
> especially if an average allocation on your typical application is small.<br>
<br>
<br>
Good point.  I will run our test suite with 8-byte shadow granularity and<br>
do some measurements.<br></blockquote><div><br></div><div>try 16 as well. </div><div>Depending on your typical code and default alignment, I would expect 8 or 16 to be the best. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In general, the memory constraint hasn't been as big an issue as I<br>
initially thought.  The mitigating factor is that we are focused on unit<br>
tests as opposed to running the full blown application.<br>
<br>
<br>
> The pointers are 32-bit, right?<br>
> Given how RAM-constrained your environment is, maybe you should consider<br>
something more like HWASAN instead of ASAN.<br>
> <a href="https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html" rel="noreferrer" target="_blank">https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html</a><br>
> But you may not have enough address bits. :(<br>
<br>
Pointers are 32 bits.  Interesting idea, but I agree I don't think we have<br>
enough bits.  Even ignoring the sparsely used lower addresses, DDR + cache<br>
bit leaves us with only 2 bits.<br>
<br>
Thanks,<br>
<br>
Walter<br>
</blockquote></div></div>