[clang] [clang-offload-bundler] Fix finding installed llvm-objcopy

[mgorny]

Summary

Allow finding installed llvm-objcopy in PATH if it's not present
in the directory containing clang-offload-bundler. This is the case
if clang is being built stand-alone, and llvm-objcopy is already
installed while the c-o-b tool is still present in build directory.

This is consistent with how e.g. llvm-symbolizer is found in LLVM.
However, most of similar searches in LLVM and Clang are performed
without special-casing the program directory.

Fixes r369955.

[abrachet]

clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

469

I'd be fine removing this FWIW. Is there a high chance they will be in the same directory? I think on a mac, there is very little chance this will be true because Apple preinstalls clang in /usr/bin, but not llvm-objcopy that would have to go in /usr/local/bin. Is it enough of an optimization to keep? Up to you I think.

[sdmitriev]

Looks good.

clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

assert(NumberOfProcessedInputs <= NumberOfInputs &&
            "Processing more inputs that actually exist!");
     assert(HostInputIndex != ~0u && "Host input index not defined.");
 
     // If this is not the last output, we don't have to do anything.
     if (NumberOfProcessedInputs != NumberOfInputs)
       return false;
 
     // Find llvm-objcopy in order to create the bundle binary.
     ErrorOr<std::string> Objcopy = sys::findProgramByName(
         "llvm-objcopy", sys::path::parent_path(BundlerExecutable));
+    if (!Objcopy)
+      Objcopy = sys::findProgramByName("llvm-objcopy");
     if (!Objcopy) {
       errs() << "error: unable to find 'llvm-objcopy' in path.\n";
       return true;
     }
 
     // We write to the output file directly. So, we close it and use the name
     // to pass down to llvm-objcopy.
     OS.close();