[LLD] [MinGW] Interpret an empty -entry option as no entry point

[mstorsjo]

This fixes #93309, and seems to match how GNU ld handles this case.

[llvmbot]

@llvm/pr-subscribers-lld

@llvm/pr-subscribers-lld-coff

Author: Martin Storsjö (mstorsjo)

Changes

This fixes #93309, and seems to match how GNU ld handles this case.

Also treat a missing -entry argument as no entry point; this also is what GNU ld does in this case.

---

Full diff: https://github.com/llvm/llvm-project/pull/96055.diff

2 Files Affected:

• (modified) lld/MinGW/Driver.cpp (+5-1)
• (modified) lld/test/MinGW/driver.test (+3)

diff --git a/lld/MinGW/Driver.cpp b/lld/MinGW/Driver.cpp
index 0d55d5b3672a4..0527839ba6f02 100644
--- a/lld/MinGW/Driver.cpp
+++ b/lld/MinGW/Driver.cpp
@@ -223,8 +223,12 @@ bool link(ArrayRef<const char *> argsArr, llvm::raw_ostream &stdoutOS,
     StringRef s = a->getValue();
     if (args.getLastArgValue(OPT_m) == "i386pe" && s.starts_with("_"))
       add("-entry:" + s.substr(1));
-    else
+    else if (!s.empty())
       add("-entry:" + s);
+    else
+      add("-noentry");
+  } else {
+    add("-noentry");
   }
 
   if (args.hasArg(OPT_major_os_version, OPT_minor_os_version,
diff --git a/lld/test/MinGW/driver.test b/lld/test/MinGW/driver.test
index 619fee8dee7c1..ef5fc8b4aa905 100644
--- a/lld/test/MinGW/driver.test
+++ b/lld/test/MinGW/driver.test
@@ -60,6 +60,9 @@ RUN: ld.lld -### foo.o -m i386pep --entry bar 2>&1 | FileCheck -check-prefix=ENT
 RUN: ld.lld -### foo.o -m i386pep -entry=bar 2>&1 | FileCheck -check-prefix=ENTRY %s
 RUN: ld.lld -### foo.o -m i386pep --entry=bar 2>&1 | FileCheck -check-prefix=ENTRY %s
 ENTRY: -entry:bar
+RUN: ld.lld -### foo.o -m i386pep -e bar -entry= 2>&1 | FileCheck -check-prefix=NOENTRY --implicit-check-not=-entry %s
+RUN: ld.lld -### foo.o -m i386pep 2>&1 | FileCheck -check-prefix=NOENTRY %s
+NOENTRY: -noentry
 
 RUN: ld.lld -### foo.o -m i386pep -mllvm bar -mllvm baz 2>&1 | FileCheck -check-prefix=MLLVM %s
 MLLVM: -mllvm:bar -mllvm:baz

[alvinhochun]

Also treat a missing -entry argument as no entry point; this also is what GNU ld does in this case.

Not sure if this is necessary or correct. Wouldn't this break the default entry points (e.g. WinMainCRTStartup/mainCRTStartup)?

[mstorsjo]

Also treat a missing -entry argument as no entry point; this also is what GNU ld does in this case.

Not sure if this is necessary or correct. Wouldn't this break the default entry points (e.g. WinMainCRTStartup/mainCRTStartup)?

There's indeed no strict need for this part of the change, I just chose to include it for completeness (as I remember noticing this behaviour in GNU ld before). And yes, you're right that it would change the behaviour of default entry points.

However the default entry point behaviour never really comes into play in mingw configurations; as long as you drive the linking via GCC/Clang, it always passes one -e option or another, so it practically never will hit that case anyway. (And that choice depends on whether you're passing -municode when linking.) So practically, the case only matters if you're invoking ld.lld directly.

If you feel it's nice to keep the lld style autodetection here, we could of course do that, but practically it makes not much difference either way.

[alvinhochun]

as long as you drive the linking via GCC/Clang, it always passes one -e option or another, so it practically never will hit that case anyway

Does it...? When I run clang++.exe -### -x c++ - I don't see any entry point flags in the ld.lld invocation.

[mstorsjo]

as long as you drive the linking via GCC/Clang, it always passes one -e option or another, so it practically never will hit that case anyway

Does it...? When I run clang++.exe -### -x c++ - I don't see any entry point flags in the ld.lld invocation.

Oh, you're absolutely right, it isn't - I clearly misremembered, and didn't check correctly.

Indeed, we shouldn't be touching this aspect of it - the default behaviour in GNU ld is also more nuanced than this.

[mstorsjo]

as long as you drive the linking via GCC/Clang, it always passes one -e option or another, so it practically never will hit that case anyway

Does it...? When I run clang++.exe -### -x c++ - I don't see any entry point flags in the ld.lld invocation.

Oh, you're absolutely right, it isn't - I clearly misremembered, and didn't check correctly.

Indeed, we shouldn't be touching this aspect of it - the default behaviour in GNU ld is also more nuanced than this.

Pushed an update to remove this part of the change now.

[alvinhochun]

Thanks, LGTM.