llvm dev - Jun 2012 - [LLVMdev] MemorySanitizer, a tool that finds uninitialized reads and more

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?

> I expect
> that both will often be used together...
>
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120618/56ee5ee2/attachment.html>

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.

Joerg

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.

--kcc


> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120618/686c8030/attachment.html>