[LLVMdev] MemorySanitizer, a tool that finds uninitialized reads and more

[Joerg Sonnenberger]

On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote:
> On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> > wrote:
> 
> > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote:
> > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger <
> > joerg at britannica.bec.de
> > > > wrote:
> > >
> > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote:
> > > > > Another difference from Memcheck is that we propose to use 8 shadow
> > bits
> > > > > per byte of application memory and use a
> > > > > direct shadow mapping (for 64-bit linux that is just clearing 46-th
> > bit
> > > > of
> > > > > the application memory address).
> > > > > This greatly simplifies the instrumentation code and avoids races on
> > > > shadow
> > > > > updates
> > > > > (Memcheck is single-threaded so races are not a concern there.
> > > > > Memcheck uses 2 shadow bits per byte with a slow path storage that
> > uses 8
> > > > > bits per byte).
> > > >
> > > > Can you make it possible for ASAN to share the same layout?
> > >
> > >
> > > Not sure I understand you. What layout?
> >
> > Shadow memory.
> >
> 
> yes, asan and msan shadow could co-exist, at least on 64-bit linux with
> disabled ASLR.
> But the problem is that the memory overheads will multiply -- the combined
> tool will be more expensive to use
> than two separate tools together.

Which is what I am asking about. I don't really have a problem with
using a one-to-one mapping, if it makes both ASAN and MSAN more
efficient in terms of runtime overhead.

Joerg