[llvm-dev] JIT client - late cross references
Lang Hames via llvm-dev
llvm-dev at lists.llvm.org
Tue Aug 21 08:49:29 PDT 2018
Hi Bjoern,
I do not think there is any practical way to do this yourself, short of
writing your own RuntimeDyld implementation.
The reason is that you cannot resolve a symbol to an address until you have
compiled it down to an object file, but in the case of circular reference
you would need to compile both IR Modules to object files before either
could be patched up, and by that stage it is too late to patch either up at
the IR level.
What is the use case for trying to resolve these references yourself,
rather than letting RuntimeDyld do it for you?
Cheers,
Lang.
On Mon, Aug 6, 2018 at 4:20 AM Gaier, Bjoern via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello everyone,
>
>
>
> I'm still a beginner with the LLVM and the process of jitting a BC file at
> runtime as a JIT client - but I'm really interested into this subject.
>
>
>
> In my current use case I have two BC files which have cross references to
> each other, normally I could just add them both to the
> llvm::ExecutionEngine and they will be resolved.
>
> But I would like to resolve these cross references by myself, through the
> llvm::JITSymbolResolver but I see no way for this, since both files
> references each other.
>
>
>
> If I jit A, it will reach the undefined function from file B. So at this
> point I would have to jit B, but B references a function from A, which
> isn't completely resolved yet.
>
> Is there a way to get the addresses of the functions before the jit
> process is completed? Maybe via the section addresses and some kind of
> offset or so?
>
>
>
> Thank you for any response!
>
>
>
> Kind greetings
>
> Björn
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20180821/d0bc1468/attachment.html>
More information about the llvm-dev
mailing list