llvm dev - Mar 2020 - [ORC JIT] -Resolving cross references in a multi-process scenario

Hello LLVM-Mailing-List and Lang,

I have a very weird (or strict?) scenario and was curious if the ORC  JIT can
help me with it. Soo here it comes:

I have currently a windows process ("Runtime") which does nothing but
creating a shared memory with read, write and execute rights - and also writing
some function addresses like from printf to it.
Then I have two or more processes which are using the ORC JIT to load modules to
this shared memory, in "perspective" of the process I mentioned above
("Runtime"). The sections are remapped from the other processes to be
correct for "Runtime", also they resolve the undefined references for
"Runtime" - like for printf and so on.
This works quite well so far! Wuhuhu x3

However, there is one issue about it. Given that those two (or more processes)
are now loading modules that reference each other. Like Module A is using a
function of Module B - but Module B also uses a function of Module A. How could
I resolve those modules when they are loaded from different processes? Normally
I would use llvm-link to link those modules but in my current scenario this is
sadly not possible.

Can the ORC JIT help me with that? Can I solve this problem differently? Like
replacing all the functions of Module A that rely on Module B with function
pointers? Is something like that possible?

I know this situation is pretty uncommon but sadly I ran into that issue.

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, Takeshi Fukushima. Junichi Tajika
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200306/64d45798/attachment.html>

Hello LLVM-Mailing-List and Lang,

I played around with this problem a bit and found a way of doing this - however
I'm not sure about the consequences and if this is really a good idea.

I went trough all of the global symbols and functions being defined in the
llvm::Module and set for each of them a new section name (based on there name).
With this approach the memorymanager could tell me already the addresses of my
symbols, which I could then share with the other process. However, this approach
needed to load the module two times, first to get the future address and in a
second run to use the addresses to resolve the symbols.

The only disadvantage I noticed so far was that the overall size of the emitted
code was bigger then having the regular sections. Are there any other risks I
might have overseen?

Kind greetings
Björn


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Gaier,
Bjoern via llvm-dev
Sent: 06 March 2020 14:24
To: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Lang Hames
<lhames at gmail.com>
Subject: [llvm-dev] [ORC JIT] -Resolving cross references in a multi-process
scenario

Hello LLVM-Mailing-List and Lang,

I have a very weird (or strict?) scenario and was curious if the ORC  JIT can
help me with it. Soo here it comes:

I have currently a windows process ("Runtime") which does nothing but
creating a shared memory with read, write and execute rights - and also writing
some function addresses like from printf to it.
Then I have two or more processes which are using the ORC JIT to load modules to
this shared memory, in "perspective" of the process I mentioned above
("Runtime"). The sections are remapped from the other processes to be
correct for "Runtime", also they resolve the undefined references for
"Runtime" - like for printf and so on.
This works quite well so far! Wuhuhu x3

However, there is one issue about it. Given that those two (or more processes)
are now loading modules that reference each other. Like Module A is using a
function of Module B - but Module B also uses a function of Module A. How could
I resolve those modules when they are loaded from different processes? Normally
I would use llvm-link to link those modules but in my current scenario this is
sadly not possible.

Can the ORC JIT help me with that? Can I solve this problem differently? Like
replacing all the functions of Module A that rely on Module B with function
pointers? Is something like that possible?

I know this situation is pretty uncommon but sadly I ran into that issue.

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, Takeshi Fukushima. Junichi Tajika
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, Takeshi Fukushima. Junichi Tajika
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200317/0b15202c/attachment.html>

Hi Bjoern,

Thanks for your patience. The good news is that there is a neater way to do
this: ExecutionSession's lookup methods take a orc::SymbolState parameter
which describes the state that symbols must reach before a query can return
(See
https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In
your case you want to use orc::SymbolState::Resolved, which will cause the
query to return as soon as the searched-for symbols have been assigned an
address.

So if your process is generating a set of symbols that may need to be
transmitted to other sessions then you would write something like:

auto Syms = ES.lookup(SearchOrder, SymbolsToTransmit, LookupKind::Static,
SymbolState::Resolved);
if (!Syms)
  reportError(Syms.takeError());
sendSymbolsToRemote(*Syms);

Out of interest -- Is it necessary for your JIT itself to be split across
two or more processes? I had always anticipated having a single
ExecutionSession attached to the target process and then running just the
compilers on other processes. That gives you a star-like IPC network with N
+ 1 connections: One between the execution session and each of the N
compilers, and one between the execution session and the target processs.
In your model it sounds like the risk is that you may end up with N(N + 1)
IPC links with every execution session having to communicate with every
other and also with the target process.

-- Lang.

On Tue, Mar 17, 2020 at 12:34 AM Gaier, Bjoern <Bjoern.Gaier at
horiba.com>
wrote:
> Hello LLVM-Mailing-List and Lang,
>
>
>
> I played around with this problem a bit and found a way of doing this –
> however I’m not sure about the consequences and if this is really a good
> idea.
>
>
>
> I went trough all of the global symbols and functions being defined in the
> llvm::Module and set for each of them a new section name (based on there
> name). With this approach the memorymanager could tell me already the
> addresses of my symbols, which I could then share with the other process.
> However, this approach needed to load the module two times, first to get
> the future address and in a second run to use the addresses to resolve the
> symbols.
>
>
>
> The only disadvantage I noticed so far was that the overall size of the
> emitted code was bigger then having the regular sections. Are there any
> other risks I might have overseen?
>
>
>
> Kind greetings
>
> Björn
>
>
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Gaier,
> Bjoern via llvm-dev
> *Sent:* 06 March 2020 14:24
> *To:* LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Lang
Hames <
> lhames at gmail.com>
> *Subject:* [llvm-dev] [ORC JIT] -Resolving cross references in a
> multi-process scenario
>
>
>
> Hello LLVM-Mailing-List and Lang,
>
>
>
> I have a very weird (or strict?) scenario and was curious if the ORC  JIT
> can help me with it. Soo here it comes:
>
>
>
> I have currently a windows process ("Runtime") which does nothing
but
> creating a shared memory with read, write and execute rights - and also
> writing some function addresses like from printf to it.
>
> Then I have two or more processes which are using the ORC JIT to load
> modules to this shared memory, in "perspective" of the process I
mentioned
> above ("Runtime"). The sections are remapped from the other
processes to be
> correct for "Runtime", also they resolve the undefined references
for
> "Runtime" - like for printf and so on.
>
> This works quite well so far! Wuhuhu x3
>
>
>
> However, there is one issue about it. Given that those two (or more
> processes) are now loading modules that reference each other. Like Module A
> is using a function of Module B - but Module B also uses a function of
> Module A. How could I resolve those modules when they are loaded from
> different processes? Normally I would use llvm-link to link those modules
> but in my current scenario this is sadly not possible.
>
>
>
> Can the ORC JIT help me with that? Can I solve this problem differently?
> Like replacing all the functions of Module A that rely on Module B with
> function pointers? Is something like that possible?
>
>
>
> I know this situation is pretty uncommon but sadly I ran into that issue.
>
>
>
> 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, Takeshi Fukushima.
> Junichi Tajika
> 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, Takeshi Fukushima.
> Junichi Tajika
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200318/a3acfc90/attachment.html>