[LLD] MinGW driver __image_base__ alternate name wrongly defined on i386 if no `-m` option from gcc

[jeremyd2019]

in lld/MinGW/Driver.cpp, there is:

llvm-project/lld/MinGW/Driver.cpp

Lines 524 to 527 in eb70253

	if (args.getLastArgValue(OPT_m) == "i386pe")
	add("-alternatename:__image_base__=___ImageBase");
	else
	add("-alternatename:__image_base__=__ImageBase");

This does not seem to work in the default case:

$ g++ hello.cc -fuse-ld=lld
warning: failed to compute relocation: IMAGE_REL_I386_REL32, Invalid data was encountered while parsing the file
ld.lld: error: undefined symbol: __image_base__
>>> referenced by /t/r/msys2-runtime-3.3/src/msys2-runtime/winsup/cygwin/lib/_cygwin_crt0_common.cc:188
>>>               libmsys-2.0.a(_cygwin_crt0_common.o):(.text)
collect2: error: ld returned 1 exit status

As a workaround I can do:

$ g++ hello.cc -fuse-ld=lld -Wl,-m,i386pe

$ ./a.exe
Hello

@mstorsjo @mati865

[mstorsjo]

I'm confused about what you think is wrong here.

As far as I know, the literal symbol name is __image_base__, for both i386 and x86_64, i.e. no extra underscore prefix on i386 for this one.

If -Wl,-m,i386pe helps, then it seems like GCC is invoking ld.lld with something else than -m i386pe by default, and that's the problem - not with how LLD handles the __image_base__ symbol? Can you add -v to the GCC invocation (without this -Wl,-m option) and see what it is passing?

[jeremyd2019]

$ g++ hello.cc -fuse-ld=lld -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-msys/13.3.0/lto-wrapper.exe
Target: i686-pc-msys
Configured with: /t/r/gcc/src/gcc-13.3.0/configure --build=i686-pc-msys --prefix=/usr --libexecdir=/usr/lib --enable-bootstrap --enable-static --enable-shared --enable-shared-libgcc --enable-version-specific-runtime-libs --with-arch=pentium4 --with-tune=generic --disable-multilib --disable-sjlj-exceptions --enable-__cxa_atexit --with-dwarf2 --enable-languages=c,c++,lto --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --disable-libssp --disable-win32-registry --disable-symvers --with-gnu-ld --with-gnu-as --disable-isl-version-check --enable-checking=release --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --enable-libstdcxx-filesystem-ts
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.3.0 (GCC)
COLLECT_GCC_OPTIONS='-fuse-ld=lld' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentium4' '-dumpdir' 'a-'
 /usr/lib/gcc/i686-pc-msys/13.3.0/cc1plus.exe -quiet -v -idirafter /usr/lib/gcc/i686-pc-msys/13.3.0/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-msys/13.3.0/../../../../i686-pc-msys/lib/../../include/w32api hello.cc -quiet -dumpdir a- -dumpbase hello.cc -dumpbase-ext .cc -mtune=generic -march=pentium4 -version -fuse-ld=lld -o /tmp/ccZxisAe.s
GNU C++17 (GCC) version 13.3.0 (i686-pc-msys)
        compiled by GNU C version 13.3.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP

warning: MPFR header version 4.2.1 differs from library version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/i686-pc-msys/13.3.0/../../../../i686-pc-msys/include"
ignoring duplicate directory "/usr/lib/gcc/i686-pc-msys/13.3.0/../../../../i686-pc-msys/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-msys/13.3.0/include/c++
 /usr/lib/gcc/i686-pc-msys/13.3.0/include/c++/i686-pc-msys
 /usr/lib/gcc/i686-pc-msys/13.3.0/include/c++/backward
 /usr/lib/gcc/i686-pc-msys/13.3.0/include
 /usr/lib/gcc/i686-pc-msys/13.3.0/include-fixed
 /usr/include
 /usr/lib/gcc/i686-pc-msys/13.3.0/../../../../include/w32api
End of search list.
Compiler executable checksum: 91915367b841ef4c4b6dae8707f1ee53
COLLECT_GCC_OPTIONS='-fuse-ld=lld' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentium4' '-dumpdir' 'a-'
 /usr/lib/gcc/i686-pc-msys/13.3.0/../../../../i686-pc-msys/bin/as.exe -v -o /tmp/cczrWzTj.o /tmp/ccZxisAe.s
GNU assembler version 2.44 (i686-pc-msys) using BFD version (GNU Binutils) 2.44
COMPILER_PATH=/usr/lib/gcc/i686-pc-msys/13.3.0/:/usr/lib/gcc/i686-pc-msys/13.3.0/:/usr/lib/gcc/i686-pc-msys/:/usr/lib/gcc/i686-pc-msys/13.3.0/:/usr/lib/gcc/i686-pc-msys/:/usr/lib/gcc/i686-pc-msys/13.3.0/../../../../i686-pc-msys/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-msys/13.3.0/:/usr/lib/gcc/i686-pc-msys/13.3.0/../../../../i686-pc-msys/lib/:/usr/lib/gcc/i686-pc-msys/13.3.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-fuse-ld=lld' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentium4' '-dumpdir' 'a.'
 /usr/lib/gcc/i686-pc-msys/13.3.0/collect2.exe -plugin /usr/lib/gcc/i686-pc-msys/13.3.0/msys-lto_plugin.dll -plugin-opt=/usr/lib/gcc/i686-pc-msys/13.3.0/lto-wrapper.exe -plugin-opt=-fresolution=/tmp/ccnG5Is6.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmsys-2.0 -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --wrap _Znwj --wrap _Znaj --wrap _ZdlPv --wrap _ZdaPv --wrap _ZnwjRKSt9nothrow_t --wrap _ZnajRKSt9nothrow_t --wrap _ZdlPvRKSt9nothrow_t --wrap _ZdaPvRKSt9nothrow_t -Bdynamic --dll-search-prefix=msys- --large-address-aware --tsaware -fuse-ld=lld /usr/lib/gcc/i686-pc-msys/13.3.0/../../../crt0.o /usr/lib/gcc/i686-pc-msys/13.3.0/crtbegin.o -L/usr/lib/gcc/i686-pc-msys/13.3.0 -L/usr/lib/gcc/i686-pc-msys/13.3.0/../../../../i686-pc-msys/lib -L/usr/lib/gcc/i686-pc-msys/13.3.0/../../.. /tmp/cczrWzTj.o -lstdc++ -lgcc_s -lgcc -lmsys-2.0 -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc /usr/lib/gcc/i686-pc-msys/13.3.0/../../../default-manifest.o /usr/lib/gcc/i686-pc-msys/13.3.0/crtend.o
warning: failed to compute relocation: IMAGE_REL_I386_REL32, Invalid data was encountered while parsing the file
ld.lld: error: undefined symbol: __image_base__
>>> referenced by /t/r/msys2-runtime-3.3/src/msys2-runtime/winsup/cygwin/lib/_cygwin_crt0_common.cc:188
>>>               libmsys-2.0.a(_cygwin_crt0_common.o):(.text)
collect2: error: ld returned 1 exit status

I think it's not passing a -m at all and relying on a default, but maybe I'm missing something. This is what I think is wrong: it's not dealing with the case where there is no -m passed and it is going to be using whatever the default is.

[mstorsjo]

I think it's not passing a -m at all and relying on a default, but maybe I'm missing something. This is what I think is wrong: it's not dealing with the case where there is no -m passed and it is going to be using whatever the default is.

Right. I would ideally fix this in GCC, so that it always passes an -m option. AFAIK it already always does this for mingw targets. (I wonder since when it does this though - I haven't been involved in setting that up I think, but I think it always has done that as long as I've been involved here.)

This setup with an implicit -m also only works as long as LLD is built with -DLLD_DEFAULT_LD_LLD_IS_MINGW=ON, otherwise a ld.lld invocation without a -m option starts the ELF side of the linker.

It probably isn't hard to do to make it pick a default if there's no -m option passed though. But then it should probably look at getDefaultTargetTriple() rather than just #ifdef __i386__.

[jeremyd2019]

lld calls getProcessTriple but apparently not getDefaultTargetTriple.

[mstorsjo]

lld calls getProcessTriple but apparently not getDefaultTargetTriple.

That's only used for choosing how to interpret quoting in response files, right? And that's relevant based on the kind of host platform - while we here are interested in the target of the (cross) compilation; it's entirely valid to have a build of LLVM with a default target triple differing from the host one.

[jeremyd2019]

it's used for figuring out how command lines should be formatted AFAICT

[mstorsjo]

Yes, exactly. Anyway, LLD doesn't normally do this kind of implicit defaults, as it's either explicit from the -m option, or implicit from the input files - so the behaviour of any build of LLD is generally (except for the command line parsing from response files) identical in behaviour across platforms. LLD_DEFAULT_LD_LLD_IS_MINGW is one deviation from that; figuring out a default -m if none is present would be another such case. But I would find it acceptable here (or at least as long as LLD_DEFAULT_LD_LLD_IS_MINGW is enabled).

[jeremyd2019]

OK, starting a build to try

--- a/lld/MinGW/Driver.cpp      2025-04-06 12:36:24.084738700 -0700
+++ b/lld/MinGW/Driver.cpp      2025-04-06 14:18:07.147632400 -0700
@@ -527,7 +527,8 @@
   for (auto *a : args.filtered(OPT_Xlink))
     add(a->getValue());

-  if (args.getLastArgValue(OPT_m) == "i386pe")
+  if (args.hasArg(OPT_m) ? args.getLastArgValue(OPT_m) == "i386pe" :
+      Triple (sys::getDefaultTargetTriple()).getArch() == Triple::x86)
     add("-alternatename:__image_base__=___ImageBase");
   else
     add("-alternatename:__image_base__=__ImageBase");

[jeremyd2019]

that works. I consider that part of the cygwin hacks I'm playing with at this point, but I could open a PR tomorrow if you think it makes sense.

[jeremyd2019]

d'oh, I saw and wondered about the entry usage of "i386pe" comparison, turns out I need to fix it too:

ld.lld: error: <root>: undefined symbol: ___msys_dll_entry@12
collect2: error: ld returned 1 exit status
clang++: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)

[jeremyd2019]

Now trying:

--- a/lld/MinGW/Driver.cpp	2025-04-06 15:06:13.686110800 -0700
+++ b/lld/MinGW/Driver.cpp	2025-04-06 15:25:20.918627000 -0700
@@ -177,6 +177,14 @@
   return "";
 }

+static inline bool isI386Target(const opt::InputArgList &args)
+{
+  auto *a = args.getLastArg(OPT_m);
+  if (a)
+    return StringRef(a->getValue()) == "i386pe";
+  return Triple (sys::getDefaultTargetTriple()).getArch() == Triple::x86;
+}
+
 namespace lld {
 namespace coff {
 bool link(ArrayRef<const char *> argsArr, llvm::raw_ostream &stdoutOS,
@@ -230,7 +238,7 @@

   if (auto *a = args.getLastArg(OPT_entry)) {
     StringRef s = a->getValue();
-    if (args.getLastArgValue(OPT_m) == "i386pe" && s.starts_with("_"))
+    if (isI386Target(args) && s.starts_with("_"))
       add("-entry:" + s.substr(1));
     else if (!s.empty())
       add("-entry:" + s);
@@ -527,7 +535,7 @@
   for (auto *a : args.filtered(OPT_Xlink))
     add(a->getValue());

-  if (args.getLastArgValue(OPT_m) == "i386pe")
+  if (isI386Target(args))
     add("-alternatename:__image_base__=___ImageBase");
   else
     add("-alternatename:__image_base__=__ImageBase");

[mstorsjo]

that works. I consider that part of the cygwin hacks I'm playing with at this point, but I could open a PR tomorrow if you think it makes sense.

Yeah I'd be ok with it. And the PR becomes simple, because any behaviour specific to the default target triple is pretty much untestable, so I wouldn't require any tests along with such a PR.