dwblaikie wrote: > > > Even if we want to have the skeleton compile unit be parsed first, we > > > would need to know this from any accelerator table entry, wether it be > > > from .debug_names or from our internal manual index. > > > > > > True enough, but I think letting this become a lazy property > > post-construction is a bit more problematic as it might lead to more > > complicated invariants/situations further downstream. By making it a > > precondition that any split unit, on construction, has the association with > > the skeleton unit - there would be fewer "interesting" situations later > > where the lookup occurs when someone isn't expecting it. The split unit > > isn't useful without the skeleton for addresses, etc, so it's not like > > delaying the skeleton lookup provides better performance, etc. > > It actually does provide better performance as we will often do the type > lookup solely in the .dwp file and determine we don't need to actually parse > and return the type because the context doesn't match. There is no need for > the skeleton unit and the address tables and lines tables in the type lookup > case. It allows us to traverse the DIE tree in the .dwp file without ever > needing to possibly do an expensive lookup by DWO ID for DWARF4, when it > actually isn't needed. We have an accessor to allow us to get the skeleton > unit if and only if we need it, and yes, most times it will be filled in > already. But when it isn't we can easily access it.
Huh, fair enough - bit surprising, but it works. Still worried about doing things a bit too lazily, more complicated states to deal with through the debugger, but fair enough. Thanks for walking me through it! https://github.com/llvm/llvm-project/pull/79544 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
