[Lldb-commits] [lldb] [lldb/DWARF] Search fallback to the manual index in GetFullyQualified… (PR #102123)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Mon Aug 12 23:10:40 PDT 2024


labath wrote:

> I guess what I was proposing was more about deleting code than adding it. We must always have at most _one_ index, but we have a lot of code allowing for the situation of two indices (manual & {apple, dwarf}).

Okay. I think I understand now what you meant -- which was to have each compile unit to store some sort of a reference to "its" index (is that right)? If that's the case, then I don't think that could work. While it's true that every CU is covered by exactly one index, a single index can (and usually does) cover more than one CU, and there isn't a good way to partition it along CU boundaries. The apple indexes such shove everything into a single table, which is indexed by name (a hash of it). There's no way to efficiently query only for entries belonging to a single unit. With per-CU debug_names indexes, we could do that, but we also have multi-cu indexes, where we'd have the same problem. (For manual indexes, we could do what we want, but we'd need to be careful to not regress performance, as we currently get a large speed boost from the paralelization of the indexing step).

On top of that, this isn't really a good match for the way indexes are used. When querying the index, we usually don't know which CU we want to look at (if we did, we may not even need the index).  We just have a name, and we want the CU (and the DIE within that CU) which defines that name. Even if we created something like this, it would mean that each query would basically become a loop over all CUs to see which one contains the thing we're looking for.

https://github.com/llvm/llvm-project/pull/102123


More information about the lldb-commits mailing list