[LLVMdev] Extending AsmPrinterHandler

[Eric Christopher]

Hi Russell,

Instead of hiding bits inside the debug metadata, why not just attach
additional metadata to each instruction and look for that during emission?
You'll probably want to take a look at how things like the vectorizer are
taking advantage of metadata if you want to encode things. Then during your
front end compilation for MSIL->LLVM IR you can just attach random metadata
to some instructions. This does have the drawback that, theoretically at
least, you can strip metadata from LLVM IR and get a working binary. If
that's not the case for CoreCLR you might want to look into a way to
overload some of the instructions or ... something. Or just require people
not delete your metadata I guess.

Does this help?

-eric

On Wed, May 13, 2015 at 3:27 PM Russell Hadley <rhadley at microsoft.com>
wrote:

>  (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.  J
>
>
>
> -R
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On
> Behalf Of *Eric Christopher
> *Sent:* Wednesday, May 13, 2015 2:55 PM
>
>
> *To:* Michelle McDaniel; llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] Extending AsmPrinterHandler
>
>
>
> You could write the debug information you want into just a section in
> memory and have your external/alternate/other process/thread/etc pick it up
> on the other end? I don't see how the extra info you want to send is
> important here, you'd just be extending the existing debug support. Or I'm
> missing something at which point I'm not sure which additional questions to
> ask :)
>
>
>
> -eric
>
>
>
> On Wed, May 13, 2015 at 2:45 PM Michelle McDaniel <michelm at microsoft.com>
> wrote:
>
>  I work on the LLILC team, and we are trying to send debug line info
> through to the CoreCLR EE without using an EventListener because we need to
> send extra info (more than just available in DebugLoc) like if it’s a call
> instruction, a call site, etc. We thought extending AsmPrinterHandler would
> be useful since it seems to have information about debug locations, label
> offsets, and instruction specific information.
>
>
>
>
>
>
>
> *From:* Eric Christopher [mailto:echristo at gmail.com]
> *Sent:* Wednesday, May 13, 2015 2:37 PM
> *To:* Michelle McDaniel; llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] Extending AsmPrinterHandler
>
>
>
> We generally don't extend the AsmPrinter... can you be more specific about
> what you're trying to do?
>
> -eric
>
>
>
> On Wed, May 13, 2015 at 2:34 PM Michelle McDaniel <michelm at microsoft.com>
> wrote:
>
>  Hey everyone,
>
>
>
> I’m looking into extending AsmPrinterHandler out of tree, to communicate
> information back to the CoreCLR EE, but all of the headers are in the lib
> directory. Is there any way to extend it out of tree, or is that not
> supported? The reason I’d like to do this out of tree is because we want to
> include clr headers as well, and we don’t want to introduce that into llvm
> sources.
>
>
>
> Thanks,
>
> Michelle
>
> _______________________________________________
> 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/20150513/b60b9b00/attachment.html>