On Mon, Feb 3, 2025 at 8:01 AM Paul Robinson <pogo.w...@gmail.com> wrote:
> Also, fixed-size DIEs are much easier when quickly scanning for something; > you can derive the size of the DIE from the abbrev without having to look > at the DIE content. When you have variable-size values such as LEB128 then > you need to parse the values in order to determine where the next DIE > starts. > (Greg Clayton [LLDB] in particular has expressed a strong preference for > fixed-size values for this reason.) > --paulr > Yeah, seems like that ship's probably sailed a bit now with more LEB forms we have added in DWARFv5 (the Spilt-DWARF related forms that got back-ported to non-split DWARF too) - addrx, loclistx, exprloc, etc. But I'll certainly gather some data on fixed size records that would be made non-fixed size if I get some data on this. > > On Mon, Feb 3, 2025 at 1:09 AM Cary Coutant <ccout...@gmail.com> wrote: > >> As an alternative to the indexed proposal in 250130.1, which proposes >>> allowing a constant classed value for DW_AT_object_pointer, as an index >>> into the formal parameters of the subprogram, I was wondering how folks >>> would feel about something a bit different: >>> >>> What about a reference classed form that is a (signed) LEB128 relative >>> DIE offset - relative to the start of the DIE containing the attribute >>> value? >>> >>> This would allow for other shortenings of DIEs that are commonly nearby. >>> >>> I don't have measurements on how much it could decrease DWARF size, but >>> could maybe prototype such a thing (bit expensive, because it makes DWARF >>> byte size dependent on itself in some ways - and LLVM's DWARF generation >>> precomputes DIE offsets, etc, rather than relying on assembler relaxation) >>> >> >> Yes, it's worth discussing, but I suspect the downsides you've mentioned >> would outweigh any benefits obtained by using an offset rather than an >> index. If anything, I'd think the index would be more useful if >> you read and internalize the DIE tree. An index would also almost always be >> a single byte (and its size would be predictable), while an offset would be >> more likely to require 2 bytes. >> > More likely, mathematically, but in terms of the population in practice I think they'll be within a byte mostly. but the major motivation for this proposal is to generalize to other cases - to be able to use smaller encodings for other DIE-to-DIE references (like for DW_AT_type, DW_AT_abstract_origin, etc). We could address this with smaller fixed forms (like we have for, say, strx1, strx2, etc... before going to ULEB) - either still as CU-relative offsets, or as DIE-relative offsets (the DIE relative offsets would help ensure that a longer CU doesn't necessarily make DWARF later in that CU larger than DWARF earlier in the CU) I guess I'll have to gather some data to help motivate this. > >> -cary >> >>
-- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
