search for: processdebugloc

...; ISD::DEBUG_LOC nodes are produced when debug stoppoints are expanded. However debug stoppoints are no longer produced by the frontend since debug info is now encoded using metadata. Therefore there are no .loc directives in the output and no line number information. It looks like AsmPrinter::processDebugLoc function should be updated to check whether HasDotLocAndDotFile is set and if it is emit the .loc directive. Does this make sense? -- Richard Osborne | XMOS http://www.xmos.com

It seems to me that emitting DWARF line number information using .loc directives is currently broken. CellSPU is currently the only in tree target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it to produce any line number information. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

...010-September/034464.html which seems to be doing almost exactly what I want to do, however it was created with LLVM 2.7 in mind. Since then, from what I can tell, the LLVM MC project has been created and blown away the usefulness of the descriptions contained in that thread. (Example: AsmPrinter::processDebugLoc() no longer exists). Does anyone have any pointers on how to update this for LLVM/clang 3.0? To be more specific, I've added a special stack guard intrinsic similar to StackProtector.cpp which uses a per function random immediate instead of ___stack_chk_guard. What I am trying to accomplish...

...n DW_TAG and DW_AT IDs in Dwarf.h) and adds it to the ModuleCU (for simplicity I'm adding my DIEs to the module's debug_info section) I Added a few lines to Dwarf.cpp for emitting the correct name for my new DW_TAG and AT (useful when looking at commented assembly) Finally, in AsmPrinter::processDebugLoc() I grab the metadata from the MachineInstr and pass it to the DwarfWriter to add it to its DwarfDebug member. When the assembly is emitted, the debug_info section contains my new dwarf DIE which I've managed to retrieve from the binary with a dwarf consumer. cheers, rw. On 24 August 2010 0...

>Aaron Gray wrote: >> What I am after is to be able to emit line number information for COFF >> (Common Object File Format) object module files, basically it comes down >> to >> paired line numbers and virtual address offsets. >> >> I have not really set out to look at this yet, just feeling ahead, and >> was >> prompted by Saman's question

Hi Roger, On Mon, Aug 23, 2010 at 4:01 PM, Roger Wang <innit42 at gmail.com> wrote: > Dear all, > > I'd like to find the memory location of certain instructions in a > compiled/linked binary. During the IR phase, I tag instructions I'm > interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable > ID). I'd now like to propagate that data

Dear all, I'd like to find the memory location of certain instructions in a compiled/linked binary. During the IR phase, I tag instructions I'm interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable ID). I'd now like to propagate that data to the assembly via a custom DWARF tag I attach to each X86 instruction created from a tagged IR instruction. This will

Aaron Gray wrote: > Dear All, > > To add to this, what you want to do is find the appropriate debug stop > point intrinsic and then use it to look up the information for that > instruction. > > Here is some sample code from SAFECode that finds the debug information > associated with a CallInst (LLVM call instruction) held in the variable > CI. It uses the