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

[Lang Hames via llvm-dev]

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>