> > In 250506.2, the use of a rnglist is throwing me. I would expect the > lifetime of a vtable to be the whole program. Or did you envision the > rnglist to be the range of data/rodata addresses of the vtable object? > 2.17 clarifies that they're code addresses (i.e. text), though. >
The DW_AT_vtable_ranges attribute is for the CU, and gives a set of ranges of memory addresses for the vtables in that CU, not just one. (This is not a loclist, but a rnglist.) Typically (at least in C++), vtables are emitted in a specific section (where they can be relocated then made read-only), and could be described by a single range list entry. With COMDATs, it might take more than one range. I thought about adding DW_AT_vtable_low/high as an alternative to the range list, but it seemed like overkill. I may have to tweak the wording in 2.17 to cover the usage of range lists for vtables. I think 2.17.3, "Non-Contiguous Address Ranges," is generic enough to apply to vtable addresses as well as code addresses. If it helps the design: there are languages where vtables are not > necessarily statically allocated. For vtables that are generated dynamically, I don't know that there's anything we can do to help with accelerated access. -cary
-- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
