<div dir="ltr"><div dir="ltr">StaticLibraryDefinitionGenerator works as promised on ELF archives!</div><div dir="ltr"><br></div><div dir="ltr">I have only encountered one problem. If a static library has not been compiled with -fPIC and uses symbols from a shared library, LLJIT does not complain, but the code may crash without warning when it is executed.</div><div dir="ltr"><br></div><div>Geoff<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 28, 2020 at 11:58 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Geoff,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator work for ELF objects?</blockquote></div><div><br></div><div>They do. :)</div><div><br></div><div>I've not tested StaticLibraryDefinitionGenerator extensively on Linux. but we have a regression test checking basic usage. If you run into any trouble at all please file a bug and assign it to me.</div><div><br></div><div>-- Lang. </div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 28, 2020 at 2:05 PM Geoff Levner <<a href="mailto:glevner@gmail.com" target="_blank">glevner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator<br>
work for ELF objects?<br>
<br>
On Mon, Sep 28, 2020 at 10:57 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br>
><br>
> Hi Geoff,<br>
><br>
>> Importing symbols into the JIT from an object file or static library...?<br>
><br>
><br>
> Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components?<br>
><br>
> The high-level answer here (which we can dig into further in the BoF) is:<br>
><br>
> For object files:<br>
> - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add' method.<br>
> - For an LLJIT instance you can just call the 'addObjectFile' method.<br>
> - For the OrcV2 C API you can call the 'LLVMOrcLLJITAddObjectFile' function.<br>
><br>
> For static libraries:<br>
> - For raw OrcV2 components or an LLJIT instance you can attach a StaticLibraryDefinitionGenerator [1] to the JITDylib that you would like to load the library into. See [2] for an example.<br>
> - For the OrcV2 C API we will just need to add a method to wrap the operation above. We already have 'LLVMOrcCreateDynamicLibrarySearchGeneratorForProcess'. We should add counterparts to that to load dynamic and static libraries from paths.<br>
><br>
> -- Lang.<br>
><br>
> [1] <a href="https://github.com/llvm/llvm-project/blob/5aa56b242951ab0f0181386ea58509f19b09206e/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h#L361" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/5aa56b242951ab0f0181386ea58509f19b09206e/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h#L361</a><br>
> [2] <a href="https://github.com/llvm/llvm-project/blob/e7549dafcd33ced4280a81ca1d1ee4cc78ed253f/llvm/tools/lli/lli.cpp#L968" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/e7549dafcd33ced4280a81ca1d1ee4cc78ed253f/llvm/tools/lli/lli.cpp#L968</a><br>
><br>
><br>
> On Mon, Sep 28, 2020 at 7:18 AM Geoff Levner <<a href="mailto:glevner@gmail.com" target="_blank">glevner@gmail.com</a>> wrote:<br>
>><br>
>> Importing symbols into the JIT from an object file or static library...?<br>
>><br>
>> On Mon, Sep 28, 2020 at 5:29 AM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Andres,<br>
>>><br>
>>>> A topic that I'd find interesting is what it'd take to make it easier to<br>
>>>> use profile guided optimization in the context of JIT.  A few years back<br>
>>>> I crudely hacked this together, but it was fairly ugly. It'd be nice to<br>
>>>> make that easier.  Possibly too complicated for that type of session?<br>
>>><br>
>>><br>
>>> We couldn't go into detail, but we could kick off a discussion and identify who is interested in working on this. My pitch: We should solve this by investing in JITLink and implementing profiling (and debugger support) via ObjectLinkingLayer::Plugins. Maybe a brief overview of / discussion on how these work would be useful?<br>
>>><br>
>>> -- Lang.<br>
>>><br>
>>><br>
>>> On Fri, Sep 25, 2020 at 7:19 PM Andres Freund <<a href="mailto:andres@anarazel.de" target="_blank">andres@anarazel.de</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> On 2020-09-25 19:05:42 -0700, Lang Hames wrote:<br>
>>>> > The 2020 Virtual LLVM Developer's Meeting is coming up the week after next.<br>
>>>> > I'll be hosting a JIT Birds-of-a-Feather session on Thursday the 8th at<br>
>>>> > 10:55am PDT (See <a href="http://llvm.org/devmtg/2020-09/schedule/" rel="noreferrer" target="_blank">http://llvm.org/devmtg/2020-09/schedule/</a>). I'm planning to<br>
>>>> > run this more like a Round Table: Minimal introduction, plenty of time for<br>
>>>> > discussion.<br>
>>>> ><br>
>>>> > Does anyone have any LLVM JIT related topics that they would particularly<br>
>>>> > like to discuss at this session? Any questions that they think could be<br>
>>>> > best answered by a round-table style discussion? I'll aim to rope in the<br>
>>>> > right people and prepare answers to make sure we get the most out of the<br>
>>>> > session.<br>
>>>><br>
>>>> A topic that I'd find interesting is what it'd take to make it easier to<br>
>>>> use profile guided optimization in the context of JIT.  A few years back<br>
>>>> I crudely hacked this together, but it was fairly ugly. It'd be nice to<br>
>>>> make that easier.  Possibly too complicated for that type of session?<br>
>>>><br>
>>>> I dimly recall that the main issue was that there is no good way to<br>
>>>> extract the profile information without going through files / applying<br>
>>>> the profile data without going through files.<br>
>>>><br>
>>>> Greetings,<br>
>>>><br>
>>>> Andres Freund<br>
</blockquote></div>
</blockquote></div></div>