search for: debug_rnglist

Displaying 20 results from an estimated 52 matches for "debug_rnglist".

Did you mean: debug_rnglists
2018 Jul 12
2
debug_rnglists status
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
2018 Jul 12
2
debug_rnglists status
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...
2019 Dec 30
3
Increasing address pool reuse/reducing .o file size in DWARFv5
...DWARFv5+Split DWARF, 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,...
2020 Jan 08
2
Increasing address pool reuse/reducing .o file size in DWARFv5
...nder 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 >...
2019 Sep 24
3
Remove obsolete debug info while garbage collecting
...s is a recommendation which needs to have an additional specification. There is -fdebug-types-section implementation which follows that recommendation.  Other cases(other than type units) do not easily fit into this recommendation. There are tables which have a common header. F.e. .debug_line, .debug_rnglists, .debug_addr. It is not clear how these tables could be separated between section groups. The more important thing is the fragmentation itself. Dividing debug tables into pieces would increase debug info size. It also would significantly complicate code working with debug info. F.e. include/ll...
2020 Jan 10
2
Increasing address pool reuse/reducing .o file size in DWARFv5
...t; > > > > > > > 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 relocat...
2020 May 28
4
Range lists, zero-length functions, linker gc
...> defined as length and changing it to 1. Something which you suggested here: > http://lists.llvm.org/pipermail/llvm-dev/2020-May/141599.html. > Hmm, I don't /think/ I intended to suggest anything that would have to parse all the debug_info, even if just to fixup high_pc. I meant that debug_rnglist for the CU at least (rnglist has fewer problems - you can't accidentally terminate it early, but still has the "large functions in programs that use relatively low code addresses can't just be resolved to "addend" because then [0, length) of the large function might overlap i...
2019 Sep 25
2
Remove obsolete debug info while garbage collecting
...an additional >> specification. >> There is -fdebug-types-section implementation which follows that >> recommendation. Other cases(other than type units) do not easily fit into >> this recommendation. There are tables which have a common header. F.e. >> .debug_line, .debug_rnglists, .debug_addr. It is not clear how these tables >> could be separated between section groups. >> >> The more important thing is the fragmentation itself. Dividing debug >> tables into pieces would increase debug info size. >> It also would significantly complicate code...
2020 Jun 04
4
[Debuginfo][DWARF][LLD] Remove obsolete debug info in lld.
...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't be optimal, adjac...
2020 Jun 03
2
[Debuginfo][DWARF][LLD] Remove obsolete debug info in lld.
...WARF linker to rewrite the ranges > > > without parsing the rest of the DWARF. /technically/ this isn't guaranteed - rnglist entries > > > can be referenced either directly, or by index. If all rnglists are referenced by index, then > > > a linker could parse only the debug_rnglists section and rewrite ranges to remove any > > > address ranges that refer to optimized-out code. > > > > > > This would only be correct for rnglists that had no direct references to them (that only were > > > referenced via the indexes) - but we could either impl...
2020 Jan 13
2
Increasing address pool reuse/reducing .o file size in DWARFv5
...; 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...
2020 Jun 09
2
[Debuginfo][DWARF][LLD] Remove obsolete debug info in lld.
...gt; > 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 Work > > >...
2020 Nov 11
3
[LLD] Support DWARF64, debug_info "sorting"
...etc), so we do need to consider this approach. Mixtures would certainly be possible, and there's no guarantee the CUs would be in a nice order with 32-bit blocks before 64-bit blocks. If I follow this to its full conclusion, you could potentially end up with a single .debug_info (.debug_line, .debug_rnglists etc) input section with a mixture of DWARF32/DWARF64 sub-sections, which, if following the reordering approach, the linker might have to split up internally in order to rearrange (aside - there's some interesting crossover with ideas I've been considering regarding the Fragmented DWARF top...
2020 Nov 11
3
[LLD] Support DWARF64, debug_info "sorting"
...s approach. Mixtures would certainly be >> possible, and there's no guarantee the CUs would be in a nice order with >> 32-bit blocks before 64-bit blocks. If I follow this to its full >> conclusion, you could potentially end up with a single .debug_info >> (.debug_line, .debug_rnglists etc) input section with a mixture of >> DWARF32/DWARF64 sub-sections, which, if following the reordering approach, >> the linker might have to split up internally in order to rearrange (aside >> - there's some interesting crossover with ideas I've been considering >&gt...
2020 Jul 24
2
Switch to ld.bfd tombstone behavior by default
...tombstone value. > > > > >> - From the point of view correct parsing of DWARF 5 - it looks like > they are equally good. > > > > > >Yep, DWARFv5 is more complicated - bfd's approach would be marginally > > >better even for addr+offset encodings in debug_rnglists - since it'd > > >always produce a 0 for the addr, whereas gold/lld's behavior can in > > >some cases (eg: "void f1() { } __attribute__((nodebug)) void f2() { } > > >void f3() { }" with -fno-function-sections - you'll end up with the > > >r...
2020 Nov 11
2
[LLD] Support DWARF64, debug_info "sorting"
+James for context too (always good to include the folks from the original threads for continuity) Yeah, my general attitude there was just twofold, one that the discussion had strayed fairly far from the review (so interested parties might not see it, both because it's a targeted review thread on the noisy llvm-commits, and because fo the title not having much connection to the discussion)
2020 Jul 24
2
Switch to ld.bfd tombstone behavior by default
...>>> > >> - From the point of view correct parsing of DWARF 5 - it looks like they are equally good. >>> > > >>> > >Yep, DWARFv5 is more complicated - bfd's approach would be marginally >>> > >better even for addr+offset encodings in debug_rnglists - since it'd >>> > >always produce a 0 for the addr, whereas gold/lld's behavior can in >>> > >some cases (eg: "void f1() { } __attribute__((nodebug)) void f2() { } >>> > >void f3() { }" with -fno-function-sections - you'll end up...
2020 Jul 21
3
Switch to ld.bfd tombstone behavior by default
...ed and it could not be solved without new meaning for tombstone value. >> - From the point of view correct parsing of DWARF 5 - it looks like they are equally good. > >Yep, DWARFv5 is more complicated - bfd's approach would be marginally >better even for addr+offset encodings in debug_rnglists - since it'd >always produce a 0 for the addr, whereas gold/lld's behavior can in >some cases (eg: "void f1() { } __attribute__((nodebug)) void f2() { } >void f3() { }" with -fno-function-sections - you'll end up with the >range for f3 starting at a non-zero adden...
2020 Nov 11
0
[LLD] Support DWARF64, debug_info "sorting"
...etc), so we do need to consider this approach. Mixtures would certainly be possible, and there's no guarantee the CUs would be in a nice order with 32-bit blocks before 64-bit blocks. If I follow this to its full conclusion, you could potentially end up with a single .debug_info (.debug_line, .debug_rnglists etc) input section with a mixture of DWARF32/DWARF64 sub-sections, which, if following the reordering approach, the linker might have to split up internally in order to rearrange (aside - there's some interesting crossover with ideas I've been considering regarding the Fragmented DWARF top...
2020 May 22
2
RFC: Add DWARF support for yaml2obj
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