search for: rnglist

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

...: > > >> 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, the...

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

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

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

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

...to make dsymutil/DWARFLinker truly multi-thread? (To make dsymutil/DWARFLinker able to process each object file in a separate thread) >One way to do that would be to have a CU-local type indirection table. >DIEs reference local type numbers (like local address/string numbers - >addrx/strx/rnglistx) and that table contains either sig8 (no linker >fixups required) or the local type offsets you describe - the linker >would then only need to read this type number indirection table and >rewrite them to the final type numbers. Yes, that could be additionally done if this process would b...

...invest in solving all the above 1-4 problems and how much community interested in it. Thank you, Alexey. >> >One way to do that would be to have a CU-local type indirection table. >> >DIEs reference local type numbers (like local address/string numbers - >> >addrx/strx/rnglistx) and that table contains either sig8 (no linker >> >fixups required) or the local type offsets you describe - the linker >> >would then only need to read this type number indirection table and >> >rewrite them to the final type numbers. >> >> Yes, that could...

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

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

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

...he above 1-4 problems and how much community interested in it. > >Thank you, Alexey. > >>> >One way to do that would be to have a CU-local type indirection table. >>> >DIEs reference local type numbers (like local address/string numbers - >>> >addrx/strx/rnglistx) and that table contains either sig8 (no linker >>> >fixups required) or the local type offsets you describe - the linker >>> >would then only need to read this type number indirection table and >>> >rewrite them to the final type numbers. >>> >>&...

...eft - 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 a compliance issue) > > Things I have noticed going in recently: > > Call-site and entry-value stuff (is that complete?) > New language/dialect codes > Deleted/defaulted members is in progress > "noreturn" functions is in progress > > I can't...

...t; > > > >Thank you, Alexey. > > > > > >>> >One way to do that would be to have a CU-local type indirection > table. > > >>> >DIEs reference local type numbers (like local address/string > numbers - > > >>> >addrx/strx/rnglistx) and that table contains either sig8 (no linker > > >>> >fixups required) or the local type offsets you describe - the linker > > >>> >would then only need to read this type number indirection table and > > >>> >rewrite them to the final type n...

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

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