search for: dw_at

...RValueReference = 1 << 14 I think the right short-term solution is to use these names directly in assembly, giving us: !MDDerivedType(flags: FlagPublic | FlagRValueReference, ...) This is easy to implement and easy to CHECK against. Sound good? (Eventually, I'd like to use the `DW_AT` symbols that each of these corresponds to, but `FlagStaticMember` doesn't seem to line up with any such `DW_AT` so that will take some refactoring (and I don't think it makes sense for that to block moving the hierarchy into place).) Merging the two types of files ========================...

...All seems to work well, except that I am unable to generate debug information. However, if I run objdump -g on the generated object file, it reports that the compile unit has no children: Contents of the .debug_abbrev section: Number TAG (0x0) 1 DW_TAG_compile_unit [no children] DW_AT_producer DW_FORM_strp DW_AT_language DW_FORM_data2 DW_AT_name DW_FORM_strp DW_AT_stmt_list DW_FORM_sec_offset DW_AT value: 0 DW_FORM value: 0 The IR generated for 3.9.0 passes the IR verifier without complaint (including the debug into verifier). I can run ll...

...unable to generate debug information. > > However, if I run objdump -g on the generated object file, it reports that the compile unit has no children: > > Contents of the .debug_abbrev section: > > Number TAG (0x0) > 1 DW_TAG_compile_unit [no children] > DW_AT_producer DW_FORM_strp > DW_AT_language DW_FORM_data2 > DW_AT_name DW_FORM_strp > DW_AT_stmt_list DW_FORM_sec_offset > DW_AT value: 0 DW_FORM value: 0 > > The IR generated for 3.9.0 passes the IR verifier without complaint (including the debu...

...ctionDAGBuilder::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::processDebugLoc()...

...e right short-term solution is to use these names directly in > assembly, giving us: > > !MDDerivedType(flags: FlagPublic | FlagRValueReference, ...) > > This is easy to implement and easy to CHECK against. > > Sound good? > > (Eventually, I'd like to use the `DW_AT` symbols that each of these > corresponds to, but `FlagStaticMember` doesn't seem to line up with any > such `DW_AT` so that will take some refactoring (and I don't think it > makes sense for that to block moving the hierarchy into place).) > > Merging the two types of files...

.../tls.ll 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...

...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". > 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 inte...

...t; 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 wan...

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

...; >>> 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 t...

...l 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. >>>> >>>>> >>>>> >>>>&g...

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

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

...ause 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 th...

...t; 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 wan...

...; >>> 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 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. >>>>> >>>>>> >>&gt...

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

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

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 change is to use a single map instead of 3 maps in DwarfDebug and instead of calling DwarfDebug::getDIE|insertDIE directly, we delegate the