search for: dw_form_string

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

...> >> roadblocks. > >>> > >>> It'd be great to have more detail about the roadblocks you hit to > better > >> understand how bad/what the issues are. > >> > >> A few blocks: > >> > >> - DIEString doesn't support DW_FORM_string. DW_FORM_string support might > >> have been pulled so that we never emit it from clang, but we would want > to > >> have a unit test that covers being able to read an inlined C string > from a > >> DIE. Support won't be that hard to add, but we might not want i...

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

...orking over here and we kept running into >> roadblocks. >>> >>> It'd be great to have more detail about the roadblocks you hit to better >> understand how bad/what the issues are. >> >> A few blocks: >> >> - DIEString doesn't support DW_FORM_string. DW_FORM_string support might >> have been pulled so that we never emit it from clang, but we would want to >> have a unit test that covers being able to read an inlined C string from a >> DIE. Support won't be that hard to add, but we might not want it so that >> people...

...generating DWARF info. Adrian Prantl attempted to help me get things working over here and we kept running into roadblocks. > > It'd be great to have more detail about the roadblocks you hit to better understand how bad/what the issues are. A few blocks: - DIEString doesn't support DW_FORM_string. DW_FORM_string support might have been pulled so that we never emit it from clang, but we would want to have a unit test that covers being able to read an inlined C string from a DIE. Support won't be that hard to add, but we might not want it so that people can't use it by accident and ma...

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

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

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

I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to work and also validate the changes that I am making. There are not many DWARF unit tests other than very simple ones that test DWARF forms currently. I would like to expand this to include many more tests. I had

On Mon, Aug 10, 2020 at 5:15 AM Alexey Lapshin <avl.lapshin at gmail.com> wrote: > > Hi Jonas, > > Thank you for the comments, please find my answers below... > > On 06.08.2020 20:39, Jonas Devlieghere wrote: > > Hi Alexey, > > I should've looked at this earlier. I went through the thread again and I've > made some comments, mostly from the dsymutil