search for: dw_form_strp

Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations. nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[ 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000022: DW_AT_comp_dir [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 16...

...ot;, at progbits > L.debug_abbrev_begin: > .byte 1 # Abbreviation Code > .byte 17 # DW_TAG_compile_unit > .byte 1 # DW_CHILDREN_yes > .byte 37 # DW_AT_producer > .byte 14 # DW_FORM_strp > .byte 19 # DW_AT_language > .byte 5 # DW_FORM_data2 > .byte 3 # DW_AT_name > .byte 14 # DW_FORM_strp > .byte 17 # DW_AT_low_pc > .byte 1 # DW_FORM_...

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

...s > invalid dwarf2 offset 1849950870 > My module is a DLL built with llc+ld toolchain. Target triple: 'i686-w64-mingw32'. Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following: 0x00000296: DW_TAG_base_type [10] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] = "void") DW_AT_encoding [DW_FORM_data1] (0x00) DW_AT_byte_size [DW_FORM_data1] (0x00) .... 0x00000cf8: DW_TAG_subprogram [16] * DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) DW_AT_h...

...r metadata with right MDNode. But when I compile my new bitcode to elf file. ( clang++ -g hello.bc -o exec) I can't find my debug info when I use readelf. ( readelf -w exec > log ) There just have one TAG . Number TAG 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_low_pc DW_FORM_addr DW_AT_stmt_list DW_FORM_data4 DW_AT_comp_dir DW_FORM_strp Unknown AT value: 3fe1 DW_FORM_flag Unknown AT value: 3fe2 DW_FORM_strp I can't find other dwarf TAG in...

...loat MONKEY; > > A<MONKEY> *p; > }; > > B b; > > struct C { > typedef int MONKEY; > > A<MONKEY> *p; > }; > > C c; > > This gives this DWARF: > > +-0000003f DW_TAG_structure_type "B" > -DW_AT_name DW_FORM_strp "B" > +-00000047 DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type &...

...loat MONKEY; > > A<MONKEY> *p; > }; > > B b; > > struct C { > typedef int MONKEY; > > A<MONKEY> *p; > }; > > C c; > > This gives this DWARF: > > +-0000003f DW_TAG_structure_type "B" > -DW_AT_name DW_FORM_strp "B" > +-00000047 DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type &...

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

...is not currently possible, is there any interest in adding such access to the public DebugInfo API? Perhaps with an additional "UnmangledName" option in `DILineInfoSpecifier`. Thanks, Isaiah [1]: for example: 0x0001bb00: DW_TAG_subprogram [2] DW_AT_MIPS_linkage_name [DW_FORM_strp] ( .debug_str[0x00007934] = "julia_vcat4473") DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000913] = "vcat") [2] https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARFDebugInfoEntry.cpp#L279-L286 -------------- next part -------------- An HTML...

...loat MONKEY; > > A<MONKEY> *p; > }; > > B b; > > struct C { > typedef int MONKEY; > > A<MONKEY> *p; > }; > > C c; > > This gives this DWARF: > > +-0000003f DW_TAG_structure_type "B" > -DW_AT_name DW_FORM_strp "B" > +-00000047 DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type &...

...ell, 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 llc manually on my IR withou...

...that debug_info section was incomplete. > > Hi David, Thanks for the reply. > What command did you run, on what file, and what was the output? I ran llvm-dwarf with -verbose option. It gave me the verbose print as below 0x0000000b: DW_TAG_compile_unit [1] * DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 8.0.1 ") DW_AT_language [DW_FORM_data2] (DW_LANG_C99) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 8.0.1 ") DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000)...

...ebugInfo API? Perhaps with an additional > > "UnmangledName" option in `DILineInfoSpecifier`. > > > > Thanks, > > Isaiah > > > > [1]: for example: > > > > 0x0001bb00: DW_TAG_subprogram [2] > > DW_AT_MIPS_linkage_name [DW_FORM_strp] ( > > .debug_str[0x00007934] = "julia_vcat4473") > > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000913] > = > > "vcat") > > > > > > [2] > > > https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWA...

...loat MONKEY; > > A<MONKEY> *p; > }; > > B b; > > struct C { > typedef int MONKEY; > > A<MONKEY> *p; > }; > > C c; > > This gives this DWARF: > > +-0000003f DW_TAG_structure_type "B" > -DW_AT_name DW_FORM_strp "B" > +-00000047 DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type &...

...CT_path, DW_FORM_string This tells us each entry contains a pathname encoded as an inline string. (Which is essentially how the v4 directory table is encoded.) However, because of the FORM code, we now have whole new worlds of complication regarding where the actual string might be. We might have DW_FORM_strp which puts the actual string in the .debug_string section; eventually we could have DW_FORM_line_str (pointing to .debug_line_str) or even DW_FORM_strx (indirecting through .debug_str_offsets). Conveniently, we have the DWARFFormValue class which knows how to decode data based on what the form cod...

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

...edName" option in `DILineInfoSpecifier`. >>> > >>> > Thanks, >>> > Isaiah >>> > >>> > [1]: for example: >>> > >>> > 0x0001bb00: DW_TAG_subprogram [2] >>> > DW_AT_MIPS_linkage_name [DW_FORM_strp] ( >>> > .debug_str[0x00007934] = "julia_vcat4473") >>> > DW_AT_name [DW_FORM_strp] ( >>> .debug_str[0x00000913] = >>> > "vcat") >>> > >>> > >>> > [2] >>> > >&g...

...uot;/tmp/test.elf"); bool DwarfInitSuccess = DG.init(Triple, Path); EXPECT_TRUE(DwarfInitSuccess); uint16_t Version = 4; uint8_t AddrSize = 8; DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); DwarfGenDIE CUDie = CU.getUnitDIE(); CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C); DwarfGenDIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram); SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main"); SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U...

...gt; EXPECT_TRUE(DwarfInitSuccess); >>> uint16_t Version = 4; >>> uint8_t AddrSize = 8; >>> DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); >>> DwarfGenDIE CUDie = CU.getUnitDIE(); >>> >>> CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); >>> CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C); >>> >>> DwarfGenDIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram); >>> SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main"); >>> S...