[PATCH] D92537: [lld-macho] Implement -object_path_lto

Mon Dec 7 15:09:28 PST 2020

clayborg added a comment.

In D92537#2438256 <https://reviews.llvm.org/D92537#2438256>, @int3 wrote:

> @clayborg was hoping to get your opinion on my approach to modtime in this diff

What is the main reason for this? Is this so you can run the linker on the same set of input .o files and end up with a binary whose MD5 checksum doesn't change? The danger of this approach is that we will end up allowing any lto.o file to be loaded and linked with dsymutil or lldb. If the lto.o file is modified, we will have no way of knowing if we are loading the right file. Can we add an option for this if this is solely needed for testing? I think people in the real world are going to want the modification file set correctly. If we fix https://reviews.llvm.org/D92736 to generate the UUID with the MD5 of all of the sections that don't change with where or when the binary was built, you can end up using the UUID for verification that things are the same or correct.

================
Comment at: lld/MachO/LTO.cpp:61

+static void setModTime(StringRef path, std::time_t t) {
+  int fd;
----------------
Remove this.

If you just emit the N_OSO STABS entry for the lto.o file with zero a the value (mod time) then LLDB will not try to match the mod time of the binary and won't reject it if it doesn't match. Same goes for dsymutil.

================
Comment at: lld/MachO/LTO.cpp:110
+      // containing a STABS timestamp entry that keeps changing.
+      setModTime(filePath, 0);
+    }
----------------
Remove this (see above inline comment) and maybe special case it when emitting the N_OSO?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92537/new/

https://reviews.llvm.org/D92537