<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 5/10/12 2:17 PM, Kostya Serebryany wrote:
    <blockquote
cite="mid:CAN=P9piJnGurYYEiqpD99N1a7x24vTrgo6hcngjNbJf5rpk4dw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">[snip]<br>
        <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"> <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? <br>
        </div>
      </div>
    </blockquote>
    <br>
    The pool_register_stack call is used on individual alloca objects. 
    This is because some systems (like SAFECode) want to know the bounds
    of individual stack objects.<br>
    <br>
    What does your instrumentation with the frame description string
    look like?  If I understood that better, I could better tell you
    whether ASan should modify the pool_register_stack calls or whether
    it should just use its own instrumentation pass for that step.<br>
    <br>
    <blockquote
cite="mid:CAN=P9piJnGurYYEiqpD99N1a7x24vTrgo6hcngjNbJf5rpk4dw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <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. <br>
        </div>
      </div>
    </blockquote>
    <br>
    Well, the pool_register optimizations won't tell you if a
    malloc/free pair occurs within a function, but it can tell you
    whether all the checks on a memory object avoid using shadow
    memory.  That might reduce overhead by allowing you to skip shadow
    memory initialization for memory objects that don't need it.<br>
    <br>
    <blockquote
cite="mid:CAN=P9piJnGurYYEiqpD99N1a7x24vTrgo6hcngjNbJf5rpk4dw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <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. <br>
        </div>
      </div>
    </blockquote>
    <br>
    I see.  That makes sense.<br>
    <br>
    <br>
    <blockquote
cite="mid:CAN=P9piJnGurYYEiqpD99N1a7x24vTrgo6hcngjNbJf5rpk4dw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <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>
    </blockquote>
    <br>
    Correct.  The transform to convert lscheck to fastlscheck isn't used
    on heap objects at present because the object might have been
    freed.  The optimization can be improved by doing an analysis to see
    if the object can be freed, but that's a future enhancement.<br>
    <br>
    -- John T.<br>
    <br>
  </body>
</html>