search for: debug_loclist

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

Hi Victor, The work Wolfgang is doing should get us to the "minimum syntactically correct DWARF v5" stage, which we really wanted to have for LLVM 7.0. That is, once we have .debug_rnglists and .debug_loclists done, you can ask for DWARF 5 and get something that conforms to the spec. However, it won't conform if you ask for type units (I'm working on that) or split DWARF. If your motivation is to help reduce the number of relocations needed, then working on the .debug_addr section is definitel...

...; +some 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...

Hello Wolfgang and team, I see that you are working on support of .debug_rnglists, I am interested in the feature too, could you please point me out what else left to be done so that I could help you? -- Best Regards, Victor Leschuk | Software Engineer | Access Softek

...; +some 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...

...renced strings too? in that cas ewe'd have an interesting tradeoff of maybe using FORM_strp rather than strx - if we wanted the linker to be able to drop strings from dropped function definitions, etc) > .debug_macro contents are not tied to functions and won't be fragmented. > > .debug_loclists and .debug_rnglists should be fragmentable the same > way as .debug_info; they exist only as extensions of .debug_info, and > the range list for the CU itself is merely a concatenated set of > contributions from each constituent function, so that should Just Work > (although it won'...

I think we have to be careful here. We might want flexibility to say "I want to use a specific class" without having to specify the exact DW_FORM. Sometimes, we might even end up in an ambiguous situation and not get the result we want. For example, in DWARFv4, the DW_AT_high_pc attribute has either a Constant or an Address class, which use completely different forms, but if we have just

...- if we wanted the > > linker to be able to drop strings from dropped function definitions, > > etc) > > Future refinements are quite possible! > > > > > > .debug_macro contents are not tied to functions and won't be fragmented. > > > > > > .debug_loclists and .debug_rnglists should be fragmentable the same > > > way as .debug_info; they exist only as extensions of .debug_info, and > > > the range list for the CU itself is merely a concatenated set of > > > contributions from each constituent function, so that should Just...

On Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own

...locations. >0000000000000c57 0000001800000001 R_X86_64_64 0000000000000000 .text._"some_mangeled_name" + 0 It may be weaker than "guaranteed": working in practice. Let's look at sections that reference these large .debug_* sections (.debug_info, .debug_str, .debug_loclists, .debug_rnglists, ...): * .debug_info: the first relocation references .debug_abbrev, good indicator * .debug_names references .debug_info: the first relocation (CU offset) is a good indicator * .debug_aranges references .debug_info: the first relocation (debug_info_offset) is a good indicator *...

...rectly with gdb until 1 is not used > > for rnglists/loclists as tombstone value. > > Not quite parsing this, but I think we're on the same page - that > bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, but > absolute 0) for everything else (including debug_loclists and > debug_rnglists)" is probably the most likely to work for gdb, since > it's been deployed for a long time. > > - Dave > > PS: Fair point about base address specifiers being able to produce 0,0 > entries - wouldn't mind fixing that in LLVM if I knew of an easy...

...>> > for rnglists/loclists as tombstone value. >>> >>> Not quite parsing this, but I think we're on the same page - that >>> bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, but >>> absolute 0) for everything else (including debug_loclists and >>> debug_rnglists)" is probably the most likely to work for gdb, since >>> it's been deployed for a long time. >>> >>> - Dave >>> >>> PS: Fair point about base address specifiers being able to produce 0,0 >>> entries - wo...

>On Mon, Jul 20, 2020 at 10:32 AM Alexey Lapshin ><alapshin at accesssoftek.com> wrote: >> >> >On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> >> > >> >> >On Fri, Jul 17, 2020 at

...ombstone value. > > >>> > > >>> Not quite parsing this, but I think we're on the same page - that > > >>> bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, but > > >>> absolute 0) for everything else (including debug_loclists and > > >>> debug_rnglists)" is probably the most likely to work for gdb, since > > >>> it's been deployed for a long time. > > >>> > > >>> - Dave > > >>> > > >>> PS: Fair point about base address sp...

...glists/loclists as tombstone value. > >>> > >>> Not quite parsing this, but I think we're on the same page - that > >>> bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, but > >>> absolute 0) for everything else (including debug_loclists and > >>> debug_rnglists)" is probably the most likely to work for gdb, since > >>> it's been deployed for a long time. > >>> > >>> - Dave > >>> > >>> PS: Fair point about base address specifiers being able to produce...

...>> > >>> >> > >>> Not quite parsing this, but I think we're on the same page - that >> > >>> bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, but >> > >>> absolute 0) for everything else (including debug_loclists and >> > >>> debug_rnglists)" is probably the most likely to work for gdb, since >> > >>> it's been deployed for a long time. >> > >>> >> > >>> - Dave >> > >>> >> > >>> PS: Fair poi...

...s had already worked on DWARF5 support? >DWARF64 - that's been around for a while, and just hasn't been needed >by LLVM users thus far, it seems (until recently - where some >developers have started working on that) There already implemented debug_names table, but debug_rnglists, debug_loclists, type units - are not implemented yet. The thing which should probably be changed is that dsymutil should not have its version of code generating DWARF tables. It should call already existed DWARF5/DWARF64 implementations. Then dsymutil would always use last DWARF generators. > >> 2....

...>> > >>> Not quite parsing this, but I think we're on the same page - that >> >> > >>> bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, >> but >> >> > >>> absolute 0) for everything else (including debug_loclists and >> >> > >>> debug_rnglists)" is probably the most likely to work for gdb, >> since >> >> > >>> it's been deployed for a long time. >> >> > >>> >> >> > >>> - Dave >> >> &gt...

...Not quite parsing this, but I think we're on the same page - that >> >> >> > >>> bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, >> >> but >> >> >> > >>> absolute 0) for everything else (including debug_loclists and >> >> >> > >>> debug_rnglists)" is probably the most likely to work for gdb, >> >> since >> >> >> > >>> it's been deployed for a long time. >> >> >> > >>> >> >> >> &...

...think we're on the same page - that > > >> >> >> > >>> bfd's tombstoning "1 for debug_ranges/debug_loc, 0 (not 0+addend, > > >> >> but > > >> >> >> > >>> absolute 0) for everything else (including debug_loclists and > > >> >> >> > >>> debug_rnglists)" is probably the most likely to work for gdb, > > >> >> since > > >> >> >> > >>> it's been deployed for a long time. > > >> >> >> > &...