<div dir="ltr"><br><br><div class="gmail_quote">On Fri, May 15, 2015 at 11:52 AM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div>On 05/14/2015 03:31 PM, Reid Kleckner
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Wed, May 13, 2015 at 3:27 PM,
            Russell Hadley <span dir="ltr"><<a href="mailto:rhadley@microsoft.com" target="_blank">rhadley@microsoft.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div link="blue" vlink="purple" lang="EN-US">
                <div>
                  <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">(background)
                      The CoreCLR expects a JIT to produce a MSIL
                      bytecode offset to code offset mapping annotated
                      with a few extra bits denoting if it’s
                      prolog/epilog, or it’s a call, or if there’s
                      operands remaining on the MSIL virtual stack in
                      some cases.  Our initial prototype has the MSIL
                      offset stashed in the line number field.  We could
                      stash the extra bits in the column info but that’s
                      starting to feel too much like a hack.  We’re
                      looking for a way to 1) extend the debug metadata
                      to hold our info and get it dumped into the in
                      memory object – a new section would be fine if
                      it’s not too complicated. Or 2) a place to extract
                      the data we need when we have both encoded offset
                      and access to the instructions.  We’re looking for
                      some advice.  </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span></p>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>This sounds like it's not really debug info so much as
              a description of the stack frame that is required for
              correctness, like CFI (call frame info that describes
              prologues and epilogues) and EH action tables. You
              probably want to subclass AsmPrinterHandler and hook that
              into the pipeline along with EH and debug info generation.
              Today this requires upstream modification, but the actual
              pass code can live where ever you want. Take a look at how
              Win64Exception.cpp and others are emitting things like the
              ip2state table for __CxxFrameHandler3.</div>
            <div><br>
            </div>
            <div>Long term, if you want to 100% guarantee that the MSIL
              offset is preserved through LLVM optimizations, I think we
              need some other solution. Phillip Reames was describing a
              similar problem, and I was thinking that we should have a
              way to tack semantically important data onto a function
              call like this. The best solution I could come up with
              using existing tools was to use an invoke that unwinds to
              an artificial landing pad that ends in unreachable and
              contains the preserved data in its clause operands. LLVM
              optimizers will only merge such calls if the landingpad
              destinations are the same, and it can't merge landingpads
              with different clauses.</div>
            <div><br>
            </div>
            <div>Alternatively, it occurs to me that call sites support
              attributes, which are different from metadata in that they
              are semantically important. Optimizations cannot remove
              them. Maybe what we need is just an attribute on the call
              site?</div>
            <div><br>
            </div>
            <div>Hope that helps. :)</div>
          </div>
        </div>
      </div>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    FYI, if these are semantically important (and not just debug info)
    using metadata is a really bad idea.  We've got a similar problem
    with </div></blockquote><div><br></div><div>Agreed. I don't know that I got an answer to "is this required for correctness" or not. I thought I did, but not positive now.</div><div><br></div><div>-eric</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">information required to support deoptimization and have local
    changes which mostly solve it.  <br>
    <br>
    I hope to eventually get that upstreamed, but we're not particularly
    happy with what we've got at the moment and are the process of a
    rewrite.  If you're interested, I can try to do that rewrite
    upstream.  If I do, it'll be with the caveat that the code
    upstreamed will be *extremely* experimental and likely to change
    radically over time.</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <br>
    Philip<br>
    <br>
  </div></blockquote></div></div>