[ELF] FIx use-after-return of archive path

[ikudrin]

Summary

There is a bug in lld which on some occasions causes InputFile::ArchiveName to store incorrect value. This happens because library name allocated on stack then converted to StringRef and assigned to member variable.

[meadori]

Test case?

[ruiu]

I think a better approach would be to change the type of ArchiveName from StringRef to std::string. This patch may fix the issue, but I'm not 100% sure because it fixes only one path that can reach addFile function. There might be some other places at which we pass on-stack objects to the function.

[evgeny777]

Test case?

Any suggestions how to implement it?

[ikudrin]

I asked @evgeny777 and he let me take this revision.

[ikudrin]

• Change type of ArchiveName to std::string.
• Add a test.

[ikudrin]

• Remove "tee" in the test.

[ruiu]

LGTM

test/ELF/whole-archive-name.s

8 ↗

(On Diff #134415)

I think you can remove test/ELF/Inputs/whole-archive-name.s because you only need single .s file. Since --whole-archive links everything, you don't need to pass any .o file. I.e. you can just pass an .a file.

ELF/Driver.cpp

default:
     else
       Files.push_back(createObjectFile(MBRef));
   }
 }
 
 // Add a given library by searching it from input search paths.
 void LinkerDriver::addLibrary(StringRef Name) {
   if (Optional<std::string> Path = searchLibrary(Name))
-    addFile(*Path, /*WithLOption=*/true);
+    addFile(Saver.save(*Path), /*WithLOption=*/true);
   else
     error("unable to find library -l" + Name);
 }
 
 // This function is called on startup. We need this for LTO since
 // LTO calls LLVM functions to compile bitcode files to native code.
 // Technically this can be delayed until we read bitcode files, but
 // we don't bother to do lazily because the initialization is fast.