search for: asmprinterhandler

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] Extendin...

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 wa...

...set and access to the instructions. We’re looking for some advice. ☺ -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...

...ld register/deregister themselves at creation/destruction. This registry can then be used as a cache of already opened files from which retrieve a reference to the MemoryBuffer itself using the file path. These new interfaces would be opt-in for all users of MemoryBuffer. Back to my case, the new AsmPrinterHandler could now use the MemoryBufferRegistry of the LLVM context. If there is none or the memory buffer associated to a file path has been already deregistered (or was never registered e.g. because we are using a .ll file directly), it would open the file as usual, otherwise it would reuse the registered...

...means enabling -gline-tables-only in absence of any other debugging flag specified. A flag -masm-source for communicating the driver and cc1 will be added as well. Other FE's can provide other specific mechanisms to enable source interleave. -- llvm changes For llvm I suggest creating a new AsmPrinterHandler called, tentatively, SourceInterlave that would be responsible of printing the lines related to the instructions. SourceInterleave would take care of loading the files and making sure the source code lines are emitted as comments. This handler would be enabled through MCOptions (similar to what ha...

...ister themselves at creation/destruction. This registry can then be used as a cache of already opened files from which retrieve a reference to the MemoryBuffer itself using the file path. These new interfaces would be opt-in for all users of MemoryBuffer. >> >> Back to my case, the new AsmPrinterHandler could now use the MemoryBufferRegistry of the LLVM context. If there is none or the memory buffer associated to a file path has been already deregistered (or was never registered e.g. because we are using a .ll file directly), it would open the file as usual, otherwise it would reuse the registered...