'Re: [llvm-dev] JIT client - late cross references'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-dev
Subject:    Re: [llvm-dev] JIT client - late cross references
From:       "Gaier, Bjoern via llvm-dev" <llvm-dev () lists ! llvm ! org>
Date:       2018-08-31 12:28:09
Message-ID: TY1PR01MB0254B4C02D427D3F915DC9EEE20F0 () TY1PR01MB0254 ! jpnprd01 ! prod ! outlook ! com
[Download RAW message or body]

Hello Alex,

Thank you! This will help me a lot. Can you judge if my idea with the individual \
sections would work too? (Mentioned some mails before)

Kind greetings
Björn

-----Original Message-----
From: Alex Denisov <1101.debian@gmail.com> 
Sent: Donnerstag, 30. August 2018 16:13
To: Gaier, Bjoern <Bjoern.Gaier@horiba.com>
Cc: Lang Hames <lhames@gmail.com>; LLVM Developers Mailing List \
                <llvm-dev@lists.llvm.org>
Subject: Re: [llvm-dev] JIT client - late cross references

Hi Björn,

> I understand the basic idea but sadly... My skills in handling the IR are not very \
> high, so I can't imagine where and when to replace the calls to b() with the \
> trampoline. The only thing I can handle would be creating that trampoline variable.

Here are some links to a very similar code, it's experimental and very dirty, but you \
can see the idea there: Changing bitcode:
https://github.com/mull-project/mull/blob/d961b5e494c3bf5937c101338e470b71eee97c0e/lib/MullModule.cpp#L84

Dealing with resolvers:

https://github.com/mull-project/mull/blob/d961b5e494c3bf5937c101338e470b71eee97c0e/lib/Parallelization/Tasks/MutantExecutionTask.cpp#L38
 https://github.com/mull-project/mull/blob/d961b5e494c3bf5937c101338e470b71eee97c0e/lib/Toolchain/Resolvers/MutationResolver.cpp#L23

> Also will this approach be a problem for really time critical tasks? Since I \
> replace the call to an address ( b() ) with an call to a function pointer?

There is obviously an overhead, but you better measure it and see if it's significant \
or not.

> On 29. Aug 2018, at 16:22, Gaier, Bjoern <Bjoern.Gaier@horiba.com> wrote:
> 
> Hello Alex,
> 
> This is an interesting approach! Thank you for that!
> I understand the basic idea but sadly... My skills in handling the IR are not very \
> high, so I can't imagine where and when to replace the calls to b() with the \
> trampoline. The only thing I can handle would be creating that trampoline variable. \
>  Also will this approach be a problem for really time critical tasks? Since I \
> replace the call to an address ( b() ) with an call to a function pointer? 
> Kind greetings
> Björn
> 
> -----Original Message-----
> From: Alex Denisov <1101.debian@gmail.com>
> Sent: Mittwoch, 29. August 2018 10:40
> To: Gaier, Bjoern <Bjoern.Gaier@horiba.com>
> Cc: Lang Hames <lhames@gmail.com>; LLVM Developers Mailing List \
>                 <llvm-dev@lists.llvm.org>
> Subject: Re: [llvm-dev] JIT client - late cross references
> 
> Hi Björn,
> 
> Not sure if I got it right, but I hope it gives you a hint.
> 
> Assuming that you have the following setup:
> 
> Module A has function a()
> Module B has function b()
> 
> a() calls b()
> 
> You are loading only module A, but it fails because it cannot resolve function b(), \
> right? If so, then you can try this approach:
> 
> Create a global variable in the module A of type "pointer to b()" named, e.g., \
> b_trampoline. Replace call instruction with the load+call instructions, as \
> described in pseudocode: 
> Before:
> 
> declare b(...)
> define a(): {
> ...
> call b(%1, %2, %3)
> ...
> }
> 
> After:
> 
> @b_trampoline = <pointer to b()>
> declare b(...)
> define a(): {
> ...
> %ptr = load @b_trampoline
> call %ptr(%1, %2, %3)
> ...
> }
> 
> Then, when you load module A SymbolResolver will ask for an address of \
> b_trampoline, you can give back an address of a heap-allocated storage, i.e.: 
> ...
> uint64_t *trampolineStorage = new uint64_t; ...
> 
> SymbolResolver::findSymbol(const std::string &name) {
> if (name == "b_trampoline") {
> JITSymbolInfo((uint64_t) trampolineStorage, JITSymbolFlags::Exported)
> }
> ...
> }
> 
> Later on, when everything is loaded and you are ready to execute JITed code you can \
> fill in the trampolineStorage with the actual address, i.e.: 
> *trampolineStorage = jit.getSymbol("b").getAddress();
> 
> That should do the trick.
> 
> I still hope I got your problem right and it helps ;)
> 
> Cheers,
> Alex.
> 
> > On 29. Aug 2018, at 07:38, Gaier, Bjoern via llvm-dev <llvm-dev@lists.llvm.org> \
> > wrote: 
> > Hello Lang,
> > 
> > thank you for your response!
> > 
> > So the use case would be some kind of wrapping or just taking control.
> > Taking that Module 'A' has function a() and Module 'B' has function b() and c() - \
> > also a() calls b(). The normal resolving process would resolve the function call \
> > correct. But for some reason (like having a wrapper) I would prefer to resolve \
> > calls to b() with a call to c(), but only for module 'A'. 
> > For my own hobby-project I tried working with custom section names. When I came \
> > to allocating the memory for these sections I just kept the address and used it. \
> > Would this be suitable way too? That I allocate 'points of interest' in their own \
> > sections and keep the address? Or could it happen that these sections merge into \
> > one? Would this have negative consequences? Like using more memory or so? 
> > Kind greetings
> > Björn
> > 
> > From: Lang Hames <lhames@gmail.com>
> > Sent: Dienstag, 21. August 2018 17:49
> > To: Gaier, Bjoern <Bjoern.Gaier@horiba.com>
> > Cc: LLVM Developers Mailing List <llvm-dev@lists.llvm.org>
> > Subject: Re: [llvm-dev] JIT client - late cross references
> > 
> > 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@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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> --
> AlexDenisov
> Software Engineer, https://lowlevelbits.org
> 

_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[prev in list] [next in list] [prev in thread] [next in thread] 