<div dir="ltr"><span style="font-size:13px">Hi Russell,</span><div><span style="font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">Orc provides a way to supply your own custom code for resolving symbols - for some reason this is packaged with parameters for memory manager and a set of modules rather than a single module - maybe they figured instead of providing various custom options and complicating the API, best to just provide one big function that lets you customise everything, you can always supply basic default parameters for things you don't want to customise - which makes sense - and that's what Kaleidoscope uses.</span></blockquote><div><span style="font-size:13px"><br></span></div><div>You pretty much nailed it. While Orc and MCJIT provide the same functionality, their design goals are different. MCJIT is a black-box that takes in modules and spits out linked code. It's easy to use, but any customization requires new API to be exposed to enable/disable it, and because any change to the black box affects all MCJIT clients changes are considered relatively high-risk. Orc was designed as a component-library for building things like MCJIT - you take the bits you want off the shelf, wire them together, and you've got a custom JIT that does what you want without affecting any other JIT users - changes and customization are cheap and low-risk. In that spirit, addModuleSet provides a very flexible interface which you can then wrap in something more friendly if you don't need all its features.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">Orc also provides a class that contains a basic system for resolving symbols if you don't want to customise, and that works by just supplying it with each symbol you're going to want to look up, together with the associated function pointer - and that's what you used.</span></blockquote><div><br></div><div>MappingLayer<T> provides a StringMap symbol table, similar to what I suggested in a previous email. Once you've added a symbol, it will appear in findSymbols as if you'd JIT'd it. When your resolver looks back into the JIT to search for definitions (a standard first step for a resolver) it'll find anything you've mapped. </div><div><br></div><div>I prefer customizing the resolver (as in the example I gave in the other thread), rather than using the mapping layer. It feels cleaner to keep a distinction between the symbols owned by the JIT (which are the only ones you can find with findSymbols, unless you add the mapping layer), and the symbols the JIT needs (i.e. those found via the resolver). That said, there's no real performance difference and it's easy to switch between one scheme and the other once you have something that works, so go with whatever works for you.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 2, 2016 at 7:19 AM, Russell Wallace via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks! Comparing your code to Kaleidoscope, they are superficially very different but when you boil it down, you can see the common elements. I think the most significant difference is that where you have<div><br></div><div><div>auto compiler = std::make_unique<SimpleOrcJit>(*targetMachine);</div><div>compiler->addGlobalMapping("myAlloc", (void*)myAlloc);</div></div><div><br></div><div>Kaleidoscope has</div><div><br></div><div><div> auto resolver = createLambdaResolver(</div><div> [&](const std::string &name) {</div><div> if (auto sym = compileLayer->findSymbol(name, false))</div><div> return RuntimeDyld::SymbolInfo(sym.getAddress(), sym.getFlags());</div><div> return RuntimeDyld::SymbolInfo(nullptr);</div><div> },</div><div> [](const std::string &S) { return nullptr; });</div><div> compileLayer->addModuleSet(std::vector<Module *>(1, module),</div><div> new SectionMemoryManager(), std::move(resolver));</div></div><div><br></div><div>I'm going to guess the reason for this difference is something along the lines of:</div><div><br></div><div>Orc provides a way to supply your own custom code for resolving symbols - for some reason this is packaged with parameters for memory manager and a set of modules rather than a single module - maybe they figured instead of providing various custom options and complicating the API, best to just provide one big function that lets you customise everything, you can always supply basic default parameters for things you don't want to customise - which makes sense - and that's what Kaleidoscope uses.</div><div><br></div><div>Orc also provides a class that contains a basic system for resolving symbols if you don't want to customise, and that works by just supplying it with each symbol you're going to want to look up, together with the associated function pointer - and that's what you used.</div><div><br></div><div>Is that a more or less accurate summary of the situation?</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 2, 2016 at 12:53 PM, Stefan Gränitz <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Russel, I guess you're using ORC? Then you need a mapping layer.
Have a look at this line:<br>
<a href="https://github.com/weliveindetail/JitFromScratch/blob/example/own-externals/JitFromScratch.cpp#L38" target="_blank">https://github.com/weliveindetail/JitFromScratch/blob/example/own-externals/JitFromScratch.cpp#L38</a><br>
<br>
Best,<br>
Stefan<br>
<br>
<div>Am 02.04.16 um 11:43 schrieb Russell
Wallace via llvm-dev:<br>
</div><div><div>
<blockquote type="cite">
<div dir="ltr">Tried that, still didn't work. Then I tried making
a direct API call,
<div><br>
</div>
<div>GetProcAddress(GetModuleHandle(0),"foo")<br>
</div>
<div><br>
</div>
<div>And this works if and only if __declspec(dllexport) is
supplied. So it looks like we were both right.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Apr 2, 2016 at 9:29 AM,
NAKAMURA Takumi <span dir="ltr"><<a href="mailto:geek4civic@gmail.com" target="_blank">geek4civic@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Have you tried to add dllexport?</div>
<br>
<div class="gmail_quote">
<div>
<div>
<div dir="ltr">On Sat, Apr 2, 2016 at 4:23 PM Russell
Wallace via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">I've finally managed to extract from
Kaleidoscope one particular thing that it seems to
me should be working and isn't. Given the global
declaration
<div><br>
</div>
<div>
<div>extern "C" void foo() {}</div>
</div>
<div><br>
</div>
<div>within the same program I have</div>
<div><br>
</div>
<div>RTDyldMemoryManager::getSymbolAddressInProcess("foo")<br>
</div>
<div><br>
</div>
<div>And it's returning null. (LLVM 3.8, Windows 7
x64.) What am I missing?</div>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>