Gaier, Bjoern via llvm-dev
2020-Aug-20 10:14 UTC
[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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/cffe649d/attachment.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TestModule.cpp URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/cffe649d/attachment.ksh> -------------- next part -------------- A non-text attachment was scrubbed... Name: TestModule.asm Type: application/octet-stream Size: 4623 bytes Desc: TestModule.asm URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/cffe649d/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: BitCodeFile.bc Type: application/octet-stream Size: 6936 bytes Desc: BitCodeFile.bc URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/cffe649d/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectFile.obj Type: application/octet-stream Size: 2651 bytes Desc: ObjectFile.obj URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/cffe649d/attachment-0002.obj>
Gaier, Bjoern via llvm-dev
2020-Aug-21 11:22 UTC
[llvm-dev] ORC JIT - Incorrect support for COFF files?
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> 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>; Lang Hames <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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/ae16811d/attachment.html>
Stefan Gränitz via llvm-dev
2020-Aug-21 21:09 UTC
[llvm-dev] ORC JIT - Incorrect support for COFF files?
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> *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>; Lang > Hames <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 > “externintplanschiValue;” and “voidexternFunction();”. 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 list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- https://flowcrypt.com/pub/stefan.graenitz at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/1d28685e/attachment.html>