search for: form_strp

Re DW_FORM_string the savings is small but since it came up I thought I'd mention the idea. I agree it's not worth pursuing any further. An API to use that form explicitly (that isn't the normal debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings are concerned: DWARF 5 will ruin this because DW_FORM_strx is a ULEB; so, every DIE

...; this would be: .debug_abbrev, .debug_addr, .debug_str_offsets. > > .debug_str doesn't need to be fragmented, linkers DTRT already. (linkers deduplicate debug_str - but can they be made to remove unreferenced 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; the...

...sets. > > > > > > .debug_str doesn't need to be fragmented, linkers DTRT already. > > > > (linkers deduplicate debug_str - but can they be made to remove > > unreferenced 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) > > Future refinements are quite possible! > > > > > > .debug_macro contents are not tied to functions and won't be fragmented. > > &gt...

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