Provide an implementation of GetUUID() for remote debugging scenarios.
Return a PDB's GUID (or PDB70's Signature) as the UUID.
Differential D56229
[PECOFF] Implementation of ObjectFilePECOFF:: GetUUID() asmith on Jan 2 2019, 4:04 PM. Authored by
Details Provide an implementation of GetUUID() for remote debugging scenarios. Return a PDB's GUID (or PDB70's Signature) as the UUID.
Diff Detail Event TimelineComment Actions Should we use the GUID from the COFF Debug Directory instead? It certainly seems more appropriate, if it's there. The UUID's purpose is to match symbol to the executable, so if you use a hash of the path it might solve this one problem, but won't solve the general case. Comment Actions I would definitely encourage using something better than the file checksum as UUID, if at all possible.
Comment Actions Not quite sure but correct me if i am wrong. (1) I think the Debug Directory is optional for COFF if it does have debug information and pdb to match with. (2) The Debug Directory does not contain COFF timestamp. Using md5 seems very tentative. Please elaborate how to leverage both COFF contents and the existing GUID mentioned? Comment Actions Well, I guess I would ask what you want to do with the GUID? If you want to match it to a debug information file, then the Debug Directory is the correct way to do that, and using a hash of the file path will not even be helpful. Another option would be to check for a debug directory of type IMAGE_DEBUG_TYPE_REPRO, and if that exists, then it means that the COFF timestamp is a hash of the binary, so it should be stable. If neither of these is present, then I think we should simply return false from this function and not mislead the caller. The caller might wish to use special logic if the function returns false that says "if I couldn't get a UUID from the file, then try hashing the path and doing some kind of lookup based on that", but I don't think that should be part of this function. Comment Actions The UUID that is used in ELF and Mach-o is designed to be something that is stable in a binary after it has been linked and should be the same before and after any kind of post production (stripping symbols, stripping section content to make a stand alone symbol file, etc). When someone types "target symbols add /path/to/symbol/file/a.out" we will grab its UUID and try to match it up with an existing object file. Comment Actions I agree with the above statement. A very long time ago (for reasons which are not very important now), we decided to return a crc checksum as the UUID for ELF files without a build-id, and that's a decision that's been haunting us ever since. I think it would be good to not repeat the same mistake for COFF files. The problems with the crc elf checksum are:
So I'd propose to have this function return just the debug directory GUID, if it is there. Possibly the coff timestamp could be used as a fallback, but I don't know enough about windows/coff to say for sure. The case when we need to verify whether we have a local copy of a module for the remote debugging scenario can be handled at a different level. E.g., it already looks like the qModuleInfo packet we use does differentiate to some level the "uuid" and "md5" case https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L3539. Right now they are both used to fill in the UUID field of the module spec, but we could change that and treat each field slightly differently. For matching exes, pdbs and minidumps we would just use the UUID field, while for checking object identity we would also fall back to the md5 checksum if the UUID field is not present. Comment Actions
Comment Actions Thanks. I have a couple of small comments, but I think this is basically done.
|
Since the U(G)UID needs to be stable and match the value computed from other sources, it would be good to have a test where we check that a file has some exact UUID.
Is there any way to use yaml2obj to generate such a file? For instance, if we drop the lld-link step and yamlify the resulting dll file instead. Would that work?