[LLVMdev] JIT and libgcc_s.so

[Eric Christopher]

So this is likely just an accident rather than on purpose. There's
totally room for that to happen, but it'll be the job of the client
and not MCJIT itself.

Basically whomever should call dlopen if they want to and it's the
problem of the client application (which could be lli as the canonical
mcjit example) to link in the correct bits.

Make sense? If you can see a use case in particular that would have
this functionality being linked into mcjit we'd love to hear it, but I
haven't been able to come up with one.

-eric

On Mon, Oct 1, 2012 at 10:06 AM, Jim Grosbach <grosbach at apple.com> wrote:
> Hi James,
>
> In that scenario, it would be the responsibility of the client to implement a memory manager for the MCJIT that knows how to import those symbols from the relevant shared library (or resolve them directly to the statically compiled symbols).
>
> -Jim
>
> On Oct 1, 2012, at 3:09 AM, James Molloy <James.Molloy at arm.com> wrote:
>
>> Hi all,
>>
>> There are symbols in libgcc (and compiler-rt) that JIT-compiled modules
>> may need. These are currently linked correctly because lli and friends
>> are linked against libgcc_s.so (i.e. shared library version of libgcc,
>> so dlopen/dlsym works).
>>
>> However if a consumer links statically, dlsym won't find all compiler
>> required functions (only the ones that were required by the JIT-compiler
>> itself will be linked).
>>
>> So the question is, do we want to support users of the MCJIT linking
>> statically to libgcc/compiler-rt? Or explicitly not handle this
>> use-case?
>>
>> Cheers,
>>
>> James
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev