[lli] Make sure the exported __chkstk functions are included when exporting them

[mstorsjo]

Summary

The trick we use (since cbc2a0623a39461b56bd9eeb308ca535f03793f8)
for exporting the __chkstk function (with various per-arch names)
that is defined in a different object file, relies on the function
already being linked in (by some function referencing it).

This function does end up referenced if there's a function that
allocates more than 4 KB on the stack. In most cases, it's referenced
somewhere, but in the case of builds with LLVM_LINK_LLVM_DYLIB
enabled (so most of the code resides in a separate libLLVM-<ver>.dll)
the only code in lli.exe is the lli tool specific code and the
mingw-w64 crt startup code. In the case of GCC based MinGW i386
builds with LLVM_LINK_LLVM_DYLIB, nothing else references it though.

Manually add a reference to the function to make sure it is linked
in (from libgcc or compiler-rt builtins) so that it can be exported.

This fixes one build issue encountered in
https://github.com/msys2/MINGW-packages/pull/18002.

[mati865]

llvm/tools/lli/lli.cpp

1204

Should we update this comment?
This workaround is also required for linking to shared libraries.

[mstorsjo]

llvm/tools/lli/lli.cpp

1204

Do you mean if building an user application that does JIT, against the LLVM libraries? Yeah, the same issue applies there as well (regardless of whether it's linked shared or statically) - doing it within the lli executable just fixes it for the executable and none of the lib users. There's a TODO down below that this really should be handled by ORC.

And ideally we shouldn't just be exporting this function, ideally ORC should find the right libclang_rt.builtins*.a and link in that, it's just that the chkstk functions are the most blatant examples of it.

Put another way - I wasn't really planning on working on the JIT stuff, I just wanted to make check-llvm run successfully in mingw builds; first I tried just mark most of the JIT tests unsupported for mingw configs, but @lhames made and suggested some fixes that brought us to this point instead. The root issue isn't really solved but the tests at least run.

[mati865]

llvm/tools/lli/lli.cpp

1204

Sorry, I've put this comment in the wrong place, I meant lines 1206-1207.

Do you mean if building an user application that does JIT, against the LLVM libraries? Yeah, the same issue applies there as well (regardless of whether it's linked shared or statically) - doing it within the lli executable just fixes it for the executable and none of the lib users. There's a TODO down below that this really should be handled by ORC.

I mean without this workaround lli is not buildable when linking to shared LLVM libs (IIUC this is what happened at MSYS2). I don't expect fixing ORC here.

[mstorsjo]

llvm/tools/lli/lli.cpp

1204

Ah - indeed, this fix is precisely for the shared LLVM libs issue found in MSYS2.

I don't see how this change affects the comments on lines 1206-1207. If the JIT would link in the real libclang_rt.builtins*.a at runtime, it would find __chkstk the right way from there. Since JIT doesn't do that at the moment, we need to make sure there's another exported __chkstk symbol somewhere in a loaded DLL, that the JIT can find - hence the dllexport trick. And here we have a tweak to make the dllexport trick work "when no functions allocate a large enough stack area" - which practically is when the majority of other code is in a different DLL, i.e. the shared libs or dylibs build modes.

[mati865]

llvm/tools/lli/lli.cpp

1204

Ah, so without this hack there would be no build error. I had missed it somehow.

[lhames]

LGTM. Thanks @mstorsjo!

[mmuetzel]

Could this be backported to LLVM 17?

[mstorsjo]

In D159085#4641723, @mmuetzel wrote:

Could this be backported to LLVM 17?

The threshold for what to backport right now, as we're past RC4 and expecting the final 17.0.0 next, is rather high.

But I guess this might qualify as it is a fix for a build break. Let's leave it in git main for a few days in case something shows up somewhere (but I guess there's not many other continuous mingw builds running other than mine), but I guess we could file a request for backporting this next week and still make it in for 17.0.0.

llvm/tools/lli/lli.cpp

 // When Orc tries to resolve symbols at runtime, this succeeds in MSVC
 // configurations, somewhat by accident/luck; kernelbase.dll does export a
 // symbol named "__chkstk" which gets found by Orc, even if regular applications
 // never link against that function from that DLL (it's linked in statically
 // from a compiler support library).
 //
 // The MinGW specific symbol names aren't available in that DLL though.
 // Therefore, manually export the relevant symbol from lli, to let it be
 // found at runtime during tests.
 //
 // For real JIT uses, the real compiler support libraries should be linked
 // in, somehow; this is a workaround to let tests pass.
 //
+// We need to make sure that this symbol actually is linked in when we
+// try to export it; if no functions allocate a large enough stack area,
+// nothing would reference it. Therefore, manually declare it and add a
+// reference to it. (Note, the declarations of _alloca/___chkstk_ms/__chkstk
+// are somewhat bogus, these functions use a different custom calling
+// convention.)
+//
 // TODO: Move this into libORC at some point, see
 // https://github.com/llvm/llvm-project/issues/56603.
 #ifdef __MINGW32__
 // This is a MinGW version of #pragma comment(linker, "...") that doesn't
 // require compiling with -fms-extensions.
 #if defined(__i386__)
+#undef _alloca
+extern "C" void _alloca(void);
+static __attribute__((used)) void (*const ref_func)(void) = _alloca;
 static __attribute__((section(".drectve"), used)) const char export_chkstk[] =
     "-export:_alloca";
 #elif defined(__x86_64__)
+extern "C" void ___chkstk_ms(void);
+static __attribute__((used)) void (*const ref_func)(void) = ___chkstk_ms;
 static __attribute__((section(".drectve"), used)) const char export_chkstk[] =
     "-export:___chkstk_ms";
 #else
+extern "C" void __chkstk(void);
+static __attribute__((used)) void (*const ref_func)(void) = __chkstk;
 static __attribute__((section(".drectve"), used)) const char export_chkstk[] =
     "-export:__chkstk";
 #endif
 #endif