[llvm-dev] ORC JIT - Incorrect support for COFF files?

[Lang Hames via llvm-dev]

Hi Stefan, Bjoern,

For calls across object boundaries __dllimport now supported in
RuntimeDyld:
https://github.com/llvm/llvm-project/commit/337e131ca7de48072def7729df69434c37a66eb7.
You may just be able to mark your externs as __dllimport for this to work.
I don't recall whether __dllimport works for data symbols too, but I
suspect so -- I think it's basically an explicit GOT entry.

If anyone is ever interested in writing a JITLink COFF implementation I
will be happy to help out or review patches -- I'd love to get better COFF
support in tree.

-- Lang.



On Fri, Aug 21, 2020 at 2:09 PM Stefan Gränitz <stefan.graenitz at gmail.com>
wrote:

> Hi Björn
>
> I made a workaround for this specific issue a long time ago for the
> Projucer C++ JIT Engine. It basically forwards the call to another stub
> that provides enough space to encode a full 64-bit address. The patch is
> based on LLVM 3.9, so I guess it won't work out-of-the-box on a recent
> release, but it may give you enough hints to figure it out on your own:
>
> https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f
>
> Alternatively, you could consider a memory manager that makes sure all
> calls are within a 32-bit range. For the code you JIT yourself, this should
> be no problem. In case you have to link against an old MSVCRT though, this
> is not possible, because it has a fixed load address that's far beyond the
> 32-bit range from any heap allocation you can make for your JITed code.
> That's been our issue back then and so this patch was the last resort.
>
> Please also note: this is for freestanding function only. I didn't
> consider member function calls, etc. (addend is always 0) because it was
> not relevant for the specific issue.
>
> Hope it helps
> Stefan
>
> On 21/08/2020 13:22, Gaier, Bjoern via llvm-dev wrote:
>
> I figured out that this problem is caused because “planschiValue” has a
> REL32 relocation and the addresses between the code and the variable
> overflows 32bit.
>
> Is there any workaround for this kind of issue?
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org>
> <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Gaier, Bjoern via
> llvm-dev
> *Sent:* 20 August 2020 12:15
> *To:* LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> <llvm-dev at lists.llvm.org>; Lang Hames <lhames at gmail.com>
> <lhames at gmail.com>
> *Subject:* [llvm-dev] ORC JIT - Incorrect support for COFF files?
>
>
>
> Hey LLVM-Mailing-List and Lang,
>
>
>
> I’m still learning how to use the ORC JIT but I finally reached the point
> to JIT and execute some code. For this purpose I created a test file
> (TestModule.cpp) and compiled it with Clang, generating two different
> files, one in the LLVM IR format and one in the Microsoft COFF format.
>
>
>
> The JIT resolves all undefined references, including “extern int
> planschiValue;” and “void externFunction();”. Using the IR Module I will
> get the correct address for “planschiValue” and the correct value – however
> this is not the case for the object file.
>
> For the object file I get (via printf from the module) the address
> 0x000002295D6B003C while the actual address is 0x00007FF71D9959A4.
>
>
>
> I’m really surprised about this, because the IR module works with no
> problem. I attach the source code, the IR file and the resulting object
> file (including its assembly file).
>
>
>
> Any ideas what I’m doing wrong?
>
>
>
> Thank you for the help in advance and kind greetings
>
> Björn
>
>
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert
> Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Junichi Tajika, Ergin
> Cansiz.
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert
> Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Junichi Tajika, Ergin
> Cansiz.
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> -- https://flowcrypt.com/pub/stefan.graenitz@gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200822/1923713b/attachment.html>