llvm dev - Oct 2019 - LLJit, Windows, exported symbols and COFFObjectFile

Hi!

So after seeing the great tutorial on the new LLJit by Lang Hames, I went
ahead and converted my llvm jitter. I much prefer this new API, btw.

It's starting to work well, except on Windows. Any extern "C"
exported
symbol leads to assertions about mismatching symbol flags. Tracing through
the inconsistency, it seems JITSymbolFlags::fromObjectSymbol returns a
different result than what the frontend (?) expects.

Namely, exported symbols in COFFObjectFiles are flagged with SF_Global, not
SF_Exported. fromObjectSymbol ignores that flag. Previously I had this
working with varying levels of success by flagging jit symbols as exported
if SF_Global exists (or alternatively have COFFObjectFile::getSymbolFlags
flag both SF_Global and SF_Exported).

But this breaks in other ways....

Looking at git blame, I can see I'm not the first one to try this hack (?),
so I wanted to ask whether there are any workarounds or planned work to get
the LLJit working on Windows?

I've attached an example llvm module that breaks.
Additionally, it seems lljit doesn't record constructors properly? Attached
a diff for a fix.

Regards, Janus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191012/46f9e293/attachment-0001.html>
-------------- next part --------------
diff --git a/lib/ExecutionEngine/Orc/LLJIT.cpp
b/lib/ExecutionEngine/Orc/LLJIT.cpp
index a80f78afe80..404e3c458f5 100644
--- a/lib/ExecutionEngine/Orc/LLJIT.cpp
+++ b/lib/ExecutionEngine/Orc/LLJIT.cpp
@@ -42,7 +42,7 @@ Error LLJIT::addIRModule(JITDylib &JD, ThreadSafeModule
TSM) {
   assert(TSM && "Can not add null module");

   if (auto Err -          TSM.withModuleDo([&](Module &M) { return
applyDataLayout(M); }))
+          TSM.withModuleDo([&](Module &M) { recordCtorDtors(M); return
applyDataLayout(M); }))
     return Err;

   return CompileLayer->add(JD, std::move(TSM), ES->allocateVModule());
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output_global_symbol_textual.ll
Type: application/octet-stream
Size: 525 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191012/46f9e293/attachment-0001.obj>

+Lang in case he's got some thoughts here. I know he's working
predominantly in MachO, so some non-MachO object file issues might linger a
little.

On Sat, Oct 12, 2019 at 8:07 AM Janus Lynggaard Thorborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi!
>
> So after seeing the great tutorial on the new LLJit by Lang Hames, I went
> ahead and converted my llvm jitter. I much prefer this new API, btw.
>
> It's starting to work well, except on Windows. Any extern "C"
exported
> symbol leads to assertions about mismatching symbol flags. Tracing through
> the inconsistency, it seems JITSymbolFlags::fromObjectSymbol returns a
> different result than what the frontend (?) expects.
>
> Namely, exported symbols in COFFObjectFiles are flagged with SF_Global,
> not SF_Exported. fromObjectSymbol ignores that flag. Previously I had this
> working with varying levels of success by flagging jit symbols as exported
> if SF_Global exists (or alternatively have COFFObjectFile::getSymbolFlags
> flag both SF_Global and SF_Exported).
>
> But this breaks in other ways....
>
> Looking at git blame, I can see I'm not the first one to try this hack
> (?), so I wanted to ask whether there are any workarounds or planned work
> to get the LLJit working on Windows?
>
> I've attached an example llvm module that breaks.
> Additionally, it seems lljit doesn't record constructors properly?
> Attached a diff for a fix.
>
> Regards, Janus
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191012/d140188b/attachment.html>