search for: dw_form_str

....section .debug_abbrev,"", at progbits .Labbrev_begin: .byte 1 # Abbreviation Code .byte 17 # DW_TAG_compile_unit .byte 1 # DW_CHILDREN_yes .byte 37 # DW_AT_producer .byte 8 # DW_FORM_string .byte 19 # DW_AT_language .byte 5 # DW_FORM_data2 .byte 3 # DW_AT_name .byte 8 # DW_FORM_string .byte 82 # DW_AT_entry_pc .byte 1 # DW_FORM_addr .byte 16...

...ccess); > >>> 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&quot...

Re DW_FORM_string the savings is small but since it came up I thought I'd mention the idea. I agree it's not worth pursuing any further. An API to use that form explicitly (that isn't the normal debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings...

...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"); >>>...

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

Dear LLVM devs, I've noticed that LLVM's assembler (and hence clang) doesn't generate debug data when assembling, even when run with "-g". Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don't have a DIE in the .debug_info section which identifies the compilation unit. (I'm not an expert on GDB, but

...suggestions would be very much appreciated. The v5 directory and file tables no longer have a fixed format; instead, we have a list of field descriptors followed by the fields for each entry in the directory or file table. Normally the directory table would have one descriptor: DW_LNCT_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 p...

..._line")); else - addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4, 0); + addSectionOffset(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_addr, + Asm->GetTempSymbol("section_line")); if (!Dir.empty()) addString(Die, dwarf::DW_AT_comp_dir, dwarf::DW_FORM_string, Dir); You probably wanted to do... @@ -1904,8 +1913,8 @@ // DW_AT_stmt_list is a offset of line number information for this // compile unit in debug_line section. if (Asm->MAI->doesDwarfUsesAbsoluteLabelForStmtList()) - addLabel(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_...

On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > > On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > >> Hello All, >> >> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run

...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, 0x1000...

...tFor(). The problem is that the same > > strings, again and again, are added to the string pool. Two attributes > > having the same string value would be analyzed (hash calculated) and > > searched inside the string pool. Even if these strings are already in > > string table(DW_FORM_strp, DW_FORM_strx). The process could be optimized > > for string tables. So that if some string from the string table were > > accessed previously then, it would keep a reference into the string pool. > > This would eliminate a lot of string pool searches. > > I'm not sure...