[LLVMdev] Extending AsmPrinterHandler
Nick Lewycky
nicholas at mxc.ca
Wed May 13 22:37:54 PDT 2015
Russell Hadley wrote:
> Thanks Eric, the pointes are appreciated. J
>
> I was a little put off by the documentation for metadata that said it
> could be dropped by LLVM at any time, as well as the extra assertion
> that the debug metadata was “special”. Is there a reasonable expectation
> that added metadata will make it to encode? (or AsmPrinter? I’m llvm
> jargon isn’t down yet)
The idea is that metadata is not guaranteed to be preserved or updated
by an llvm optimization (or other kind of transformation). The bitcode
reader/writer and .ll parser and asmprinter will of course preserve them.
Is the debug metadata handled specially such that
> it has priority over other metadata?
At the risk of being out of date (this area has changed more recently
than when I last fully understood it), most metadata is encoded sparsely
where the LLVMContext owns a single map from Value* to Metadata. Debug
info is special in that the Instruction* has a direct Metadata pointer
for debug info. This is an efficiency consideration, and has an LLVM API
difference, but has no semantic effect.
Nick
Also, if we go the separate
> metadata route, we’d need to extend all the debug helpers in the
> AsmPrinter to extract that data to a special section. Is that what
> you’re suggesting? In terms of correctness, not returning the debug info
> to CoreCLR only impacts debugging. The executable will still run. J
>
> Thanks,
>
> -R
>
> *From:*Eric Christopher [mailto:echristo at gmail.com]
> *Sent:* Wednesday, May 13, 2015 3:41 PM
> *To:* Russell Hadley; Michelle McDaniel; llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] Extending AsmPrinterHandler
>
> 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
> <mailto: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>
> [mailto: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
> <mailto: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 <mailto: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
> <mailto:echristo at gmail.com>]
> *Sent:* Wednesday, May 13, 2015 2:37 PM
> *To:* Michelle McDaniel; llvmdev at cs.uiuc.edu
> <mailto: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 <mailto: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 <mailto:LLVMdev at cs.uiuc.edu>
> http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list