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

Mon Aug 24 10:45:36 PDT 2020

Hi Bjoern,

Using dllimport on my “planschiValue” actually worked! But I have no idea
> why, because the relocation is still a REL32 if I use dumpbin…

>From memory dllimport is like a GOT access: You'll have a REL32 either way,
but instead of a REL32 directly to the variable you'll end up with a REL32
to an entry in a pointer table containing the address of the variable, and
the code sequence will change to access the variable indirectly via the
pointer you load.

-- Lang.

On Mon, Aug 24, 2020 at 12:57 AM Gaier, Bjoern <Bjoern.Gaier at horiba.com>
wrote:

> Hey Lang and Stefan,
>
>
>
> Using dllimport on my “planschiValue” actually worked! But I have no idea
> why, because the relocation is still a REL32 if I use dumpbin… So how is it
> possible for that to work?
>
> However… when I load an COFF object file, am I able to change the
> relocations to dllimport somehow? I honestly can’t imagine how this would
> work since the machine code is probably already adjusted to use a REL32… or
> something… Just wanted to ask…
>
>
>
> @Stefan Gränitz <stefan.graenitz at gmail.com> I remember your patch! How
> does it deal with extern variables though? As far as I understood from the
> code – not that I understood much – it fixes function calls by having a
> trampoline right?
>
>
>
> Thank you guys!
>
>
>
> Kind greetings
>
> Björn
>
>
>
> *From:* Lang Hames <lhames at gmail.com>
> *Sent:* 22 August 2020 19:50
> *To:* Stefan Gränitz <stefan.graenitz at gmail.com>
> *Cc:* Gaier, Bjoern <Bjoern.Gaier at horiba.com>; LLVM Developers Mailing
> List <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] ORC JIT - Incorrect support for COFF files?
>
>
>
> Hi Stefan, Bjoern,
>
>
>
> For calls across object boundaries __dllimport now supported in
> RuntimeDyld:
> https://github.com/llvm/llvm-project/commit/337e131ca7de48072def7729df69434c37a66eb7
> <https://hes32-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com%2fllvm%2fllvm%2dproject%2fcommit%2f337e131ca7de48072def7729df69434c37a66eb7&umid=9d785513-e9cd-44e5-a111-cb77401a12f6&auth=b6f66d00f8195cc5198eee21f0dbabe6af0a3180-2bd41aad154bd7e67313fcb36c401a0c65d55652>.
> 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
> <https://hes32-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com%2fweliveindetail%2fpj%2dllvm%2fcommit%2f97cd336d458ae9c73232d1b539ceefcdb2f5eb0f&umid=9d785513-e9cd-44e5-a111-cb77401a12f6&auth=b6f66d00f8195cc5198eee21f0dbabe6af0a3180-dffa61903884c3a0176d5f66111470dc6e9b9d2b>
>
> 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 list
>
> llvm-dev at lists.llvm.org
>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
>
> https://flowcrypt.com/pub/stefan.graenitz@gmail.com
>
> 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/20200824/ea309665/attachment.html>