search for: rnglists

...itable for you/your users, etc. >>There are two general requirements: >> 1) Remove (or clean) invalid debug info. > >Perhaps a simpler direct solution for your immediate needs might be a much narrower, >and more efficient linker-DWARF-awareness feature: > > With DWARFv5, rnglists present an opportunity for a DWARF 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...

...: > > >> 1) Remove (or clean) invalid debug info. > > > > > > > >Perhaps a simpler direct solution for your immediate needs might be a > much narrower, > > >and more efficient linker-DWARF-awareness feature: > > > > > > With DWARFv5, rnglists present an opportunity for a DWARF 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...

...gt; >> > > >> > > > >> > >Perhaps a simpler direct solution for your immediate needs might be a > >> much narrower, > >> > >and more efficient linker-DWARF-awareness feature: > >> > > > >> > > With DWARFv5, rnglists present an opportunity for a DWARF 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 rnglist...

...5+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,...

...t;>There are two general requirements: > >> 1) Remove (or clean) invalid debug info. > > > > >Perhaps a simpler direct solution for your immediate needs might be a much narrower, > >and more efficient linker-DWARF-awareness feature: > > > > With DWARFv5, rnglists present an opportunity for a DWARF 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...

...ments: > > >> 1) Remove (or clean) invalid debug info. > > > > > > > >Perhaps a simpler direct solution for your immediate needs might be a much narrower, > > >and more efficient linker-DWARF-awareness feature: > > > > > > With DWARFv5, rnglists present an opportunity for a DWARF 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 > > >...

Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow... >Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? > - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. There are two general requirements: 1) Remove (or clean) invalid

...ments: > > >> 1) Remove (or clean) invalid debug info. > > > > > > > >Perhaps a simpler direct solution for your immediate needs might be a much narrower, > > >and more efficient linker-DWARF-awareness feature: > > > > > > With DWARFv5, rnglists present an opportunity for a DWARF 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 > > >...

...emove (or clean) invalid debug info. > > > > > > > > > > >Perhaps a simpler direct solution for your immediate needs might be a much narrower, > > > >and more efficient linker-DWARF-awareness feature: > > > > > > > > With DWARFv5, rnglists present an opportunity for a DWARF 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 >...

...info. > > > > > > > > > > > > > >Perhaps a simpler direct solution for your immediate needs might be a much narrower, > > > > >and more efficient linker-DWARF-awareness feature: > > > > > > > > > > With DWARFv5, rnglists present an opportunity for a DWARF 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,...

...t 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, adjace...

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

.../index.html "When not otherwise constrained, sections should be emitted in input order." - https://web.stanford.edu/~ouster/cgi-bin/cs140-spring18/pintos/specs/sysv-abi-update.html/ch4.sheader.html ) So that works a treat, exactly as Paul suggested. Also works to modify the debug_ranges/rnglists section keeping list fragments in the same comdat group too - though the object size overhead there is probably higher than worthwhile, given the size of the contributions versus the size of ELF sections/groups/etc. If someone really wants to trim their ranges/rnglists down for size - I think a lin...

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

...; > >> > > > > >> > > > >Perhaps a simpler direct solution for your immediate needs might be a much narrower, >> > > > >and more efficient linker-DWARF-awareness feature: >> > > > > >> > > > > With DWARFv5, rnglists present an opportunity for a DWARF 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 b...

On Wed, Oct 9, 2019 at 1:33 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > From: David Blaikie <dblaikie at gmail.com> > >> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto: > paul.robinson at sony.com> wrote: > >> There are many bits of DWARF-5 that haven’t been implemented. > > > > Got a short list, by chance? > > I

...>> > > > >Perhaps a simpler direct solution for your immediate needs > might be a much narrower, > > >> > > > >and more efficient linker-DWARF-awareness feature: > > >> > > > > > > >> > > > > With DWARFv5, rnglists present an opportunity for a DWARF > 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...

...pport? >> >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. > >Superficially, type units wouldn't be on the list of features (like >DWARF64 - it's optional) I'd try to support in dsymutil - since their >size overhead is more justified for a DWARF-agnostic linker that'...

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

...> 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. >>> Superficially, type units wouldn't be on the list of features (like >>> DWARF64 - it's optional) I'd try to support in dsymutil - since their >>> size overhead is more justified for a...