<div style="font-family: arial, helvetica, sans-serif"><font size="2"><br><br><div class="gmail_quote">On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote:<br>
> On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a><br>
> > wrote:<br>
><br>
> > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote:<br>
> > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger <<br>
> > <a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a><br>
> > > > wrote:<br>
> > ><br>
> > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote:<br>
> > > > > Another difference from Memcheck is that we propose to use 8 shadow<br>
> > bits<br>
> > > > > per byte of application memory and use a<br>
> > > > > direct shadow mapping (for 64-bit linux that is just clearing 46-th<br>
> > bit<br>
> > > > of<br>
> > > > > the application memory address).<br>
> > > > > This greatly simplifies the instrumentation code and avoids races on<br>
> > > > shadow<br>
> > > > > updates<br>
> > > > > (Memcheck is single-threaded so races are not a concern there.<br>
> > > > > Memcheck uses 2 shadow bits per byte with a slow path storage that<br>
> > uses 8<br>
> > > > > bits per byte).<br>
> > > ><br>
> > > > Can you make it possible for ASAN to share the same layout?<br>
> > ><br>
> > ><br>
> > > Not sure I understand you. What layout?<br>
> ><br>
> > Shadow memory.<br>
> ><br>
><br>
> yes, asan and msan shadow could co-exist, at least on 64-bit linux with<br>
> disabled ASLR.<br>
> But the problem is that the memory overheads will multiply -- the combined<br>
> tool will be more expensive to use<br>
> than two separate tools together.<br>
<br>
</div></div>Which is what I am asking about. I don't really have a problem with<br>
using a one-to-one mapping, if it makes both ASAN and MSAN more<br>
efficient in terms of runtime overhead.<br></blockquote><div><br></div><div>one-to-one mapping will make ASAN much less efficient. </div><div>I meant that we may have both mappings (1:1 for MSAN and 8:1 for ASAN) in the same process, but it makes little sense to me. </div>
<div><br></div><div>--kcc </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Joerg<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></font></div>