<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 lang="EN-US" link="blue" vlink="purple">
<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>