[LLD] [MinGW] Print errors/warnings in lld-link with a "ld.lld" prefix

[mstorsjo]

Summary

Pass the original argv[0] to the coff linker, as the coff linker uses
the basename of argv[0] as the log prefix.

This makes error messages to be printed with a "ld.lld:" prefix
instead of "lld-link:". The current "lld-link:" prefix can be confusing
to users, as they're invoking the MinGW linker (and might not even have
a lld-link executable).

Keep the first argument as lld-link when printing the command line, to
make it an actually reproducible standalone command.

To actually test the effect of this, we'd have to actually do linking
from the test/MinGW subdirectory (which we don't do so far) and
have that link trigger an error.

Do you think it's necessary to make a standalone failing link test
to test the effect of this, or is it good as is?

[rnk]

To actually test the effect of this, we'd have to actually do linking
from the test/MinGW subdirectory (which we don't do so far) and
have that link trigger an error.

Do you think it's necessary to make a standalone failing link test
to test the effect of this, or is it good as is?

I think mingw lld can certainly have integration tests. I think it's better to focus on testing at the smallest testable boundary, which is the argument translation layer, but tactical integration testing is also valuable.

I don't think it's strictly necessary in this case, but if you'd like to add one, go for it.

[mstorsjo]

In D104526#2827401, @rnk wrote:

To actually test the effect of this, we'd have to actually do linking
from the test/MinGW subdirectory (which we don't do so far) and
have that link trigger an error.

Do you think it's necessary to make a standalone failing link test
to test the effect of this, or is it good as is?

I think mingw lld can certainly have integration tests. I think it's better to focus on testing at the smallest testable boundary, which is the argument translation layer, but tactical integration testing is also valuable.

I don't think it's strictly necessary in this case, but if you'd like to add one, go for it.

Thanks! Yes, overall it wouldn't be any big issue to have such tests (as it's all within the lld project anyway, it doesn't depend on other tools) - but I'll think I'll skip this time; if the code was written this way from the start, it's not something I think we'd think of needing a testcase for anyway.

lld/MinGW/Driver.cpp

bool mingw::link(ArrayRef<const char *> argsArr, bool canExitEarly,
 
   if (args.hasArg(OPT__HASH_HASH_HASH))
     return true;
 
   // Repack vector of strings to vector of const char pointers for coff::link.
   std::vector<const char *> vec;
   for (const std::string &s : linkArgs)
     vec.push_back(s.c_str());
+  // Pass the actual binary name, to make error messages be printed with
+  // the right prefix.
+  vec[0] = argsArr[0];
   return coff::link(vec, canExitEarly, stdoutOS, stderrOS);
 }

lld/test/MinGW/driver.test

 RUN: ld.lld -### -shared -m i386pe -e _DllMainCRTStartup@12 foo.o | FileCheck -check-prefix I386-ENTRY %s
 I386-ENTRY: -entry:DllMainCRTStartup@12
 
 RUN: ld.lld -### -m i386pep foo.o --whole-archive bar.a --no-whole-archive baz.a | FileCheck -check-prefix WHOLE-ARCHIVE %s
 RUN: ld.lld -### -m i386pep foo.o -whole-archive bar.a -no-whole-archive baz.a | FileCheck -check-prefix WHOLE-ARCHIVE %s
 WHOLE-ARCHIVE: foo.o -wholearchive:bar.a baz.a
 
 RUN: ld.lld -### -m i386pep foo.o | FileCheck -check-prefix MINGW-FLAG %s
-MINGW-FLAG: -lldmingw
+MINGW-FLAG: lld-link -lldmingw
 
 RUN: ld.lld -### -m i386pep foo.o --exclude-all-symbols | FileCheck -check-prefix EXCLUDE-ALL %s
 RUN: ld.lld -### -m i386pep foo.o -exclude-all-symbols | FileCheck -check-prefix EXCLUDE-ALL %s
 EXCLUDE-ALL: -exclude-all-symbols
 
 RUN: ld.lld -### -m i386pep foo.o --export-all-symbols | FileCheck -check-prefix EXPORT-ALL %s
 RUN: ld.lld -### -m i386pep foo.o -export-all-symbols | FileCheck -check-prefix EXPORT-ALL %s
 EXPORT-ALL: -export-all-symbols