clayborg wrote:

> > > Will this now work with .dwp files not having UUID?
> > 
> > 
> > No. If binairies have UUIDs (GNU build IDs), they need to match right now. 
> > That is larger fix that involves adding a "enum UUIDFlavor" to the UUIDs so 
> > we can ensure we aren't comparing two different things.
> > What Alexander is talking about is if we have a GNU build ID in `<exe>`, 
> > the `<exe>.debug` file will have the same UUID, but llvm-dwp currently 
> > doesn't copy the GNU build ID over into the `.dwp` file. This causes LLDB 
> > to not allow the .dwp file to be loaded. The problem is if the .dwp file 
> > doesn't have a UUID, it will make one up by calculating a CRC of the file 
> > itself, and then we will compare a GNU build ID from `<exe>` to the CRC 
> > calculated by the `.dwp` file and they won't match.
> > @dwblaikie do you know how accurate the DWO ID is? Can we avoid relying on 
> > matching up the UUID on the .dwp file and solely rely on allowing it to be 
> > loaded and rely on the DWO IDs matching between the skeleton unit and the 
> > .dwo unit? If so, there is an easy fix I can make to this patch to solve 
> > that problem.
> 
> Not sure I follow. For .dwo files path is described in Skeleton CU: 
> DW_AT_comp_dir/DW_AT_dwo_name. The DWP file can have multiple CUs with 
> different DWO IDs.

Exactly. The question is, if a have one `a.out.dwp` file that is out of date, 
and one of the .dwo files was recompiled into the `a.out` binary, but the 
`a.out.dwp` file wasn't recreated and if it was actually allowed to be loaded 
without comparing the GNU build ID, will the DWO ID be unique if the skeleton 
unit has a `DW_AT_dwo_name` with "foo.o" that has a DWO ID of `0x123` and if we 
lookup up "foo.o" in the old .dwp file, will the DWO ID mismatch be enough for 
us to ensure we don't load the .dwo info. If the answer is yes, which implied 
the DWO ID is some sort of checksum or signature that always changes when a 
specific file is rebuilt, then it is ok to not match a UUID on a .dwp file. 
Seeing as no .dwp files actually have a GNU build ID right now unless people 
manually add it, it seems like we should allow loading any .dwp regardless of 
the lack of a GNU build ID and deal with the mismatches from the DWO ID. If the 
DWO ID is just a hash of the file path or something that isn't guaranteed to be 
unique with each new build, then we need the UUID in the .dwp file.

https://github.com/llvm/llvm-project/pull/81067
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to