<div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If it helps the design: there are languages where vtables are not<br>necessarily statically allocated.</blockquote><div><br></div><div>For vtables that are generated dynamically, I don't know that there's anything we can do to help with accelerated access.</div><div><br></div><div>-cary</div><div><br></div></div></div>