I was just independently investigating the exact same issue pointed by the OP here, and was also looking into the DW_IDX_parent solution. Glad to have found this discussion.
it must quickly find two pieces of information: 1. the parent pool entry, and 2. the parent pool entry’s name.
the name index is not designed for this kind of reverse lookup
@jeffreytan81 I don’t think we need to perform the reverse lookup here. We know the parent’s name (since we have the entire parent chain), so we know its hash in the table, and therefore we know which offsets have that name. If the DW_IDX_parent is one such offset, we have a match.
DW_IDX_parent can represent either the parent pool entry index […] or the parent pool entry offset
I agree it doesn’t matter much, but on page 141, lines 22-24, it says that:
Parent debugging information entry, a reference to the index entry for the parent. This is represented as the offset of the entry relative to the start of the entry pool.
More generally though, I think the bigger problem of template / simple / canonical names remain: when we are looking for A::B::C, the spelling of “B” may be different in the table and in what LLDB is querying (see the template examples provided in this thread). Right now I don’t see a way to reconcile DW_IDX_parent with the template canonical name problem, unless we can guarantee that LLDB’s context query will use the same spelling used in the table.