<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Okay.  We can then have a loadcheck() and a storecheck().<br>

    <br>
    Do you consider the atomic intrinsics (e.g., compare and swap) to be
    stores, </div></blockquote><div><br></div><div>It's fine to treat those as stores. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
or do we need an lscheck() that checks operations that
    perform a load and a store?<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>>> pool register stack(void * p, int size)</div>
      <div>asan needs more information for the stack than just pointer
        and size. Currently, there is a extra constant string with frame
        description.</div>
    </blockquote>
    <br></div>
    First, there are separate instrumentation passes for adding
    pool_register_stack(), pool_register_global(), and
    pool_register_heap().  If a tool does not find one of these
    functions useful, it can simply omit the pass that adds them.<br></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">

    <br>
    Second, regarding the extra parameters, my plan is to have each tool
    run tool-specific passes to add parameters as needed.  For example,
    SAFECode would add a pool handle argument and, if used as a
    debugging tool, source line and file name arguments.  I assume ASan
    can have a pass that adds the frame description argument.  If that's
    not possible, please let me know.<br></div></blockquote><div><br></div><div>Ok. What I still don't understand: do you plan to call pool_register_stack for every alloca or for the whole frame? </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 bgcolor="#FFFFFF" text="#000000">
    <br>
    Third, I am curious to know whether generic optimization of
    registration calls could aid ASan.  Optimizing away a pool_register
    call basically means that all run-time checks on pointers to that
    memory have either been proven safe or are performed using
    fastlscheck/fastgepcheck.  This can speed up SAFECode, but can it
    also speed up ASan?</div></blockquote><div><br></div><div>Yes, such optimizations are possible.</div><div>E.g. if we have a malloc/free pair and the pointer does not escape he current function, a lot of simplifications can be done. </div>
<div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><blockquote type="cite"><div>Asan modifies the whole stack frame at once, not every single
        alloca separately.</div>
      <div>size must be size_t </div>
      <div><br>
      </div>
      <div>>> pool register global(void * p, int size):</div>
      <div>This is very slow for cases when we have millions of
        globals. </div>
      <div>asan uses a callback which takes an array of globals as a
        parameter. </div>
      <div>Also, asan modifies the global (adding a redzone at right). </div>
      <div>size must be size_t <br>
      </div>
    </blockquote>
    <br></div>
    Good point; it would make more sense to have pool_register_global
    take an array of globals and their size.<br></div></blockquote><div><br></div><div>And then again asan needs to pass more than the addresseses and sizes. Not a big deal, of course. </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 bgcolor="#FFFFFF" text="#000000">
    <br>
    For the redzones, adding them would be done by an ASan-specific
    transform.<div class="im"><blockquote type="cite">
      <div>>> pool unregister(void * p):</div>
      <div>For performance, we will need separate unregister calls for
        heap, stack and globals. <br>
      </div>
    </blockquote>
    <br></div>
    Okay, but just out of curiosity, what performance advantage do you
    get by distinguishing between them?</div></blockquote><div><br></div><div>Some of them will need to be inlined. If you don't distinguish the types it may be harder. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im"><blockquote type="cite">
      <div>>> convert lscheck checks to fastlscheck</div>
      <div>For asan this is useless (though harmless)</div>
    </blockquote>
    <br></div>
    Actually, I'm not sure if that is true.  If I understand correctly,
    an lscheck in ASan will need to perform a load from shadow memory
    and perform a comparison.  A fastlscheck, on the other hand, does
    two comparisons.  </div></blockquote><div><br></div><div>yea, good point. A couple of arithmetic instructions is usually better than a load. </div><div>This will have to fire only when the pointer is known to be alive (not dangling).</div>
<div><br></div><div>--kcc  </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">If you suffer a cache miss in the shadow memory, I
    think an lscheck could take longer than a fastlscheck.<br>
    <br>
    Also, fastlscheck is easier to optimize.  Since you know the bounds
    of the memory object to which the pointer belongs, you may be able
    to optimize away one or both of the comparisons.<br>
    <br>
    -- John T.<br>
    <br>
  </div>

</blockquote></div><br>