search for: loclist

...s > Supplementary objects > Ah, thanks for the list - mostly I'm interested in cases where Clang's output is not valid DWARFv5 when requested - the new features DWARFv5 enables/allows but doesn't require are lower priority to me. Which I don't think too much is left - DWARFv5 loclists in split DWARF is one I know of & might get to if someone else doesn't do it before me - I'm currently improving loclist emission (quality of implementation - using fewer address pool entries & just general code cleanup to share some of teh implementation with rnglist emission, not...

...> Ah, thanks for the list - mostly I'm interested in cases where Clang's > > output is not valid DWARFv5 when requested - the new features DWARFv5 > > enables/allows but doesn't require are lower priority to me. Which I > > don't think too much is left - DWARFv5 loclists in split DWARF is one > > I know of & might get to if someone else doesn't do it before me - I'm > > currently improving loclist emission (quality of implementation - using > > fewer address pool entries & just general code cleanup to share some of > > teh i...

...; DW_AT_decl_file ("ref.cc") >> DW_AT_decl_line (9) >> DW_AT_type (0x00000037 "int") >> >> 0x0000007f: DW_TAG_variable >> DW_AT_location (indexed (0x1) loclist = >> 0x00000023: >> [0x0000000000400490, 0x00000000004004a0): >> DW_OP_implicit_pointer 0x76 +0) <----- refVar points to var >> DW_AT_name ("refVar") >> DW_AT_decl_file ("ref.cc&quot...

.../home/alok/openllvm/llvm-project_derefval/build.d/david.cc") >> DW_AT_call_line (10) >> DW_AT_call_column (0x03) >> >> 0x00000088: DW_TAG_formal_parameter >> DW_AT_location (indexed (0x0) loclist = >> 0x00000010: >> [0x00000000004004c6, 0x00000000004004d4): >> DW_OP_explicit_pointer, DW_OP_lit3) >> DW_AT_abstract_origin (0x00000055 "p") >> ------------ >> >> Please note that DW_OP_explicit_p...

..., or not by default at all/only under a flag? So, I've brought this up a few times before - that DWARFv5 does a pretty good job of reducing relocations (& reducing .o file size with Split DWARF) by allowing many uses of addresses to include some kind of address+offset (debug_rnglists and loclists allowing "base_address" then offset_pairs (an improvement over similar functionality in DWARFv4 because the offset pairs can be uleb encoded - so they can be quite compact)) But one place that DWARFv5 misses to reduce relocations further is direct addresses from debug_info, such as DW_A...

Hi llvm-dev, cfe-dev, It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention-- 1. Language aspects 2. Location mostly optimized out ones 3. DebugInfo conformance to DWARF-5 To avoid getting conflicted with some body

...v=<register EAX not in topmost frame>, abbrev_size=<register EAX not in topmost frame>, str=<register EAX not in topmost frame>, str_size=<register EAX not in topmost frame>, line=<register EAX not in topmost frame>, line_size=<register EAX not in topmost frame>, loclist=<register EAX not in topmost frame>, loclist_size=0x0) [/home/dex/wine-0.9.42/dlls/dbghelp/dwarf.c:2217] in dbghelp (0x0033f288) 7 0x7ec4669c elf_load_debug_info_from_map+0x49c(module=0x12f988, fmap=0x33f440, pool=<register EAX not in topmost frame>, ht_symtab=0x33f490) [/home/dex/win...

...ally flush out a few more issues (or >> >not -but build confidence that there aren't more issues) I think is an >> >appropriate way to roll out a change like this. >> >> >(minor doubt: I wonder how well the bfd tombstoning works in DWARFv5 >> >(rnglists/loclists) or in debug_range/debug_loc that uses base address >> >specifiers, where the zero-without-addend doesn't have a chance to >> >make an empty range (because it's not a start/end pair, it's a >> >start+offset pair - so the offset remains non-zero)... if bfd &gt...

...e other debugger people (Pavel - wasn't sure which email address you > prefer, feel free to let me know (privately or publicly) for future > reference) > > I work at Google & we're certainly interested in DWARFv5 compliance - I'm > currently working on improving debug_loclist emission to share more address > pool entries ( https://reviews.llvm.org/D68620 ) which includes some > improvements to llvm-dwarfdump to go with that. (Pavel's working on further > improvements https://reviews.llvm.org/D68271 ) > > I haven't looked at/started on the loclist...

...e other debugger people (Pavel - wasn't sure which email address you > prefer, feel free to let me know (privately or publicly) for future > reference) > > I work at Google & we're certainly interested in DWARFv5 compliance - I'm > currently working on improving debug_loclist emission to share more address > pool entries ( https://reviews.llvm.org/D68620 ) which includes some > improvements to llvm-dwarfdump to go with that. (Pavel's working on further > improvements https://reviews.llvm.org/D68271 ) > > I haven't looked at/started on the loclist...

...>not -but build confidence that there aren't more issues) I think is > an > > >> >appropriate way to roll out a change like this. > > >> > > >> >(minor doubt: I wonder how well the bfd tombstoning works in DWARFv5 > > >> >(rnglists/loclists) or in debug_range/debug_loc that uses base > address > > >> >specifiers, where the zero-without-addend doesn't have a chance to > > >> >make an empty range (because it's not a start/end pair, it's a > > >> >start+offset pair - so the off...

...nce that there aren't more issues) I think is an >>> > >> >appropriate way to roll out a change like this. >>> > >> >>> > >> >(minor doubt: I wonder how well the bfd tombstoning works in DWARFv5 >>> > >> >(rnglists/loclists) or in debug_range/debug_loc that uses base address >>> > >> >specifiers, where the zero-without-addend doesn't have a chance to >>> > >> >make an empty range (because it's not a start/end pair, it's a >>> > >> >start+offse...

...inue to write the latter in assembly, but there is a lot that could be improved about the experience of writing "correct" dwarf. Ideally, I'd have a mode where I can just write the logical DIE structure (tags, attributes and their values), and the tool would split that into the abbrev/loclist/range/etc. sections. regards, pavel

...gt; > > > > > > So, I've brought this up a few times before - that DWARFv5 does a pretty > good job of reducing relocations (& reducing .o file size with Split > DWARF) by allowing many uses of addresses to include some kind of > address+offset (debug_rnglists and loclists allowing "base_address" then > offset_pairs (an improvement over similar functionality in DWARFv4 because > the offset pairs can be uleb encoded - so they can be quite compact)) > > > > But one place that DWARFv5 misses to reduce relocations further is > direct addre...

...k is an > > >>> > >> >appropriate way to roll out a change like this. > > >>> > >> > > >>> > >> >(minor doubt: I wonder how well the bfd tombstoning works in > DWARFv5 > > >>> > >> >(rnglists/loclists) or in debug_range/debug_loc that uses base > address > > >>> > >> >specifiers, where the zero-without-addend doesn't have a > chance to > > >>> > >> >make an empty range (because it's not a start/end pair, it's a > > &g...

...0) DW_AT_call_file ("/home/alok/openllvm/llvm-project_derefval/build.d/david.cc") DW_AT_call_line (10) DW_AT_call_column (0x03) 0x00000088: DW_TAG_formal_parameter DW_AT_location (indexed (0x0) loclist = 0x00000010: [0x00000000004004c6, 0x00000000004004d4): DW_OP_explicit_pointer, DW_OP_lit3) DW_AT_abstract_origin (0x00000055 "p") ------------ Please note that DW_OP_explicit_pointer denotes that following value represents de-referenced v...

...#39;t more issues) I think is an > >>> > >> >appropriate way to roll out a change like this. > >>> > >> > >>> > >> >(minor doubt: I wonder how well the bfd tombstoning works in DWARFv5 > >>> > >> >(rnglists/loclists) or in debug_range/debug_loc that uses base address > >>> > >> >specifiers, where the zero-without-addend doesn't have a chance to > >>> > >> >make an empty range (because it's not a start/end pair, it's a > >>> > >>...

...;> > >>> > >> >appropriate way to roll out a change like this. >> > >>> > >> >> > >>> > >> >(minor doubt: I wonder how well the bfd tombstoning works in DWARFv5 >> > >>> > >> >(rnglists/loclists) or in debug_range/debug_loc that uses base address >> > >>> > >> >specifiers, where the zero-without-addend doesn't have a chance to >> > >>> > >> >make an empty range (because it's not a start/end pair, it's a >> >...

...gt; > > > So, I've brought this up a few times before - that DWARFv5 does a pretty > > good job of reducing relocations (& reducing .o file size with Split > > DWARF) by allowing many uses of addresses to include some kind of > > address+offset (debug_rnglists and loclists allowing "base_address" then > > offset_pairs (an improvement over similar functionality in DWARFv4 because > > the offset pairs can be uleb encoded - so they can be quite compact)) > > > > > > But one place that DWARFv5 misses to reduce relocations further...

...; >appropriate way to roll out a change like this. >> >> > >>> > >> >> >> > >>> > >> >(minor doubt: I wonder how well the bfd tombstoning works >> in DWARFv5 >> >> > >>> > >> >(rnglists/loclists) or in debug_range/debug_loc that uses >> base address >> >> > >>> > >> >specifiers, where the zero-without-addend doesn't have a >> chance to >> >> > >>> > >> >make an empty range (because it's not a start...