clayborg wrote:

> I'm not following all of this, but it appears to be based on the premise that 
> it's OK that sometimes split units inside a DWP file are parsed before their 
> skeleton unit? Why is that OK/when/why/where is that happening?

When we have accelerator tables from lldb index cache being loaded from disk, 
we have a DIERef object for each matching name. This DIERef objects has a magic 
file index that specifies that this is from the .dwp file. When we do a type 
lookup and get these kinds of entries, we go straight to the `.dwp` file and 
load `.dwo` in the `.dwp` and this causes the issue. 

> I'd think any case where that happens would be a performance (& possibly 
> correctness bug) & it'd be better to maintain the invariant that the only way 
> you ever parse a split unit is starting from the skeleton - rather than 
> adding maps/etc to be able to backtrack to parsing the skeleton when you 
> already have the split unit.

That might mean that anytime we use _any_ DWARFDie, we will need to add 
functionality that checks with the DWARFUnit to verify if it is a .dwo unit, 
and if so, make sure its skeleton unit has been parsed. The current solution 
allows anyone to just work with the existing APIs and they will do the right 
thing and will only grab the backlink if it isn't already set. With DWARF5 it 
is cheap as the info is in the unit headers. 

Without this solution we will have to always parse the skeleton unit headers 
for the main executable and need to parse at least the first DIE in order to 
fill in the .dwo file's skeleton backlink pointer. So this can cause us to pull 
in more DWARF during type lookups.

If you are really against this approach I can search for a solution that avoids 
the maps, but I fear more hidden bugs will arise in the future without an 
approach similar to what this PR does. The current bugs either crashed the 
debug session or stopped type lookups from working. 


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

Reply via email to