search for: dw_tag

...xt, in SelectionDAGBuilder::visit() i transfer the current instruction's metadata from the DAGBuilder to the instruction's SDNode. In InstrEmitter::EmitNode() I copy the metadata from the SDNode to the MachineInstr. DwarfDebug::endModule() creates my user-defined DIE (after defining my own 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::processD...

...n they're attached to). Does this sound reasonable? I've completed the first part, attaching the MDNodes to IR instructions but I'm a bit overwhelmed by all the backend stuff. How can I identify which IR instruction an X86 instruction came from (with a view to attaching an identifying DW_TAG to it)? I've found the tag definitions in include/llvm/Support/Dwarf.h and added my own. lib/CodeGen/AsmPrinter/DwarfDebug.cpp seems to be the only place that emits dwarf data into the assembly stream. It also seems to create a DebugInfoFinder which accesses the IR instructions. Thanks for an...

...> Does this sound reasonable? > > I've completed the first part, attaching the MDNodes to IR instructions but > I'm a bit overwhelmed by all the backend stuff. > How can I identify which IR instruction an X86 instruction came from (with a > view to attaching an identifying DW_TAG to it)? > 1) LLVM IR instructions are converted into MachineInstr during instruction selection time. At this point you need to transfer your custom metadata to MachineInstr. See how DebugLoc is transfered (in CodeGen/SelectionDAG directory). 2) At AsmPrint time, while emitting your assembly i...

...results when I feed the .ll file to llc than when I feed it the clang, clang gives error messages when it doesn't like the metadata structure, llc appears not to do so. Is there another document I should look at? Should I be looking at source code? Where are the structures that start with DW_TAG's parsed? In general, what's resources does a front end implementer have in order to understand how to generate the DWARF stuff via llvm assembly source? thanks, bagel

...t;dexonsmith at apple.com> wrote: >> >> In r219010, I merged integer and string fields into a single header >> field. By reducing the number of metadata operands used in debug info, >> this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling >> of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and >> I've concluded that they will be insufficient. >> >> Instead, I'd like to implement a more aggressive plan, which as a >> side-effect cleans up the much "loved" debug info IR assembly syntax....

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000060] = "T") DW_AT_decl_file [D...

In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan, which as a side-effect cleans up the much "loved" debug info IR assembly syntax. At a high-level, the idea is to cr...

Hi, I am wondering if this behavior of creating debug info is correct. A type in compile unit entry is pointing to a type under subprogram entry?! This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579 0x0000000b: DW_TAG_compile_unit [1] * 0x00000026: DW_TAG_pointer_type [2] DW_AT_type [DW_FORM_ref4] (cu + 0x002c => {0x0000002c}) 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040...

...llc than when I > feed it the clang, clang gives error messages when it doesn't like the metadata > structure, llc appears not to do so. > > Is there another document I should look at? > > Should I be looking at source code? Where are the structures that start with > DW_TAG's parsed? > > In general, what's resources does a front end implementer have in order to > understand how to generate the DWARF stuff via llvm assembly source? We are working on a document. Here is current draft: http://wiki.llvm.org/Debug_Information - Devang

...l I wrote - it has some "unannotated" bytes because we still don't have a nice way to annotate location bytes that are DWARF expressions, but it's close - I guess those should be CHECK-NEXTs, though. In any case, you should be able to check a few lines of assembly with the # DW_AT/DW_TAG annotation comments. You'd need to add the tu3.cpp from my example if you want to demonstrate that the relocation is actually working as intended and avoiding the bogus result I showed. type-unique-simple-a.ll While I agree that having common test cases helps reduce the number of sepa...

...tated" >> bytes because we still don't have a nice way to annotate location bytes >> that are DWARF expressions, but it's close - I guess those should be >> CHECK-NEXTs, though. In any case, you should be able to check a few lines >> of assembly with the # DW_AT/DW_TAG annotation comments. >> > > I can check for ".quad .Lsection_info+38 #DW_AT_type". > Done in attached patch. > > >> You'd need to add the tu3.cpp from my example if you want to >> demonstrate that the relocation is actually working as intended an...

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_s...

...> wrote: > >> > >> In r219010, I merged integer and string fields into a single header > >> field. By reducing the number of metadata operands used in debug info, > >> this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling > >> of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and > >> I've concluded that they will be insufficient. > >> > >> Instead, I'd like to implement a more aggressive plan, which as a > >> side-effect cleans up the much "loved" debug info...

...es because we still don't have a nice way to annotate location bytes >>>> that are DWARF expressions, but it's close - I guess those should be >>>> CHECK-NEXTs, though. In any case, you should be able to check a few lines >>>> of assembly with the # DW_AT/DW_TAG annotation comments. >>>> >>> >>> I can check for ".quad .Lsection_info+38 #DW_AT_type". >>> >> Done in attached patch. >> >>> >>> >>>> You'd need to add the tu3.cpp from my example if you want to &g...

...ome "unannotated" > bytes because we still don't have a nice way to annotate location bytes > that are DWARF expressions, but it's close - I guess those should be > CHECK-NEXTs, though. In any case, you should be able to check a few lines > of assembly with the # DW_AT/DW_TAG annotation comments. > I can check for ".quad .Lsection_info+38 #DW_AT_type". > You'd need to add the tu3.cpp from my example if you want to > demonstrate that the relocation is actually working as intended and > avoiding the bogus result I showed. > type-uniqu...

...>> bytes because we still don't have a nice way to annotate location bytes >>> that are DWARF expressions, but it's close - I guess those should be >>> CHECK-NEXTs, though. In any case, you should be able to check a few lines >>> of assembly with the # DW_AT/DW_TAG annotation comments. >>> >> >> I can check for ".quad .Lsection_info+38 #DW_AT_type". >> > Done in attached patch. > >> >> >>> You'd need to add the tu3.cpp from my example if you want to >>> demonstrate that the relo...

...#39;t have a nice way to annotate location bytes >>>>>> that are DWARF expressions, but it's close - I guess those should be >>>>>> CHECK-NEXTs, though. In any case, you should be able to check a few lines >>>>>> of assembly with the # DW_AT/DW_TAG annotation comments. >>>>>> >>>>> >>>>> I can check for ".quad .Lsection_info+38 #DW_AT_type". >>>>> >>>> Done in attached patch. >>>> >>>>> >>>>> >>>>>>...

...can P. N. Exon Smith < dexonsmith at apple.com> wrote: > In r219010, I merged integer and string fields into a single header > field. By reducing the number of metadata operands used in debug info, > this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling > of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and > I've concluded that they will be insufficient. > > Instead, I'd like to implement a more aggressive plan, which as a > side-effect cleans up the much "loved" debug info IR assembly syntax. > > At a h...

Ping -Manman On Fri, Oct 4, 2013 at 7:00 PM, Manman Ren <manman.ren at gmail.com> wrote: > > Hi All, > > The first patch adds support for ref_addr. > Most of it is from r176882, but instead of always using an integer for > ref_addr, we use label + offset for relocation on non-darwin platforms. > > The second patch is a modified version of r191792. > The main

...e still don't have a nice way to annotate location bytes >>>>> that are DWARF expressions, but it's close - I guess those should be >>>>> CHECK-NEXTs, though. In any case, you should be able to check a few lines >>>>> of assembly with the # DW_AT/DW_TAG annotation comments. >>>>> >>>> >>>> I can check for ".quad .Lsection_info+38 #DW_AT_type". >>>> >>> Done in attached patch. >>> >>>> >>>> >>>>> You'd need to add the tu3.c...