[LLVMdev] Linkage question

[Vania Joloboff]

On 03/13/2013 11:01 AM, Dmitry Mikushin wrote:
> Hi Vania,
>
> If I understood correctly, you have an executable, which is JITing 
> code that has dependencies on the symbols of entire executable. In 
> case dlsym cannot find this symbol, try to link your executable with 
> -rdynamic (gcc) or --export-dynamic (ld):
>
>        -rdynamic
>            Pass the flag -export-dynamic to the ELF linker, on targets 
> that
>            support it. This instructs the linker to add all symbols, 
> not only
>            used ones, to the dynamic symbol table. This option is 
> needed for
>            some uses of "dlopen" or to allow obtaining backtraces from 
> within
>            a program.
>
> - D.
HI
Yes may be it'll work with export dynamic, but then it will export too 
many symbols.
Can we control the link resolution from the LLVM execution engine ?

> 2013/3/13 Vania Joloboff <vania.joloboff at inria.fr 
> <mailto:vania.joloboff at inria.fr>>
>
>     Hi,
>
>     We are new in LLVM...
>     We want to execute JIT'ed code that links to functions inside our
>     application
>     For example, the JIT has compiled code like
>
>     extern void open_device(Device * dev);
>     int foo_bar() { Device dev; ... ; open_device(&dev); ...;}
>     /
>     /where open_device() is a function in our own code, that
>     has initialized and called the ExecutionEngine.
>     Of course when running we get the error message
>
>     LLVM ERROR: Program used external function open_device which could
>     not be resolved!
>
>     How can we dynamically resolve such external addresses ?
>     We have seen in the documentation llvm is trying to link
>     unresolved symbols with dlsym(). In this case it fails.
>     Is there a hook we can plug in the execution engine so that we
>     control ourselves
>     the resolution of external symbols after dlsym() has failed.
>     We still want to try dlsym() first and only when it fails then
>     take control.
>
>     We do not see this in the execution engine interface.
>     Of course we want to do the resolution only once upon the first call
>     not for each call to foo_bar() like a profiling listener would do.
>
>     Comments will be appreciated...
>     Vania
>
>
>
>
>
>
>
>
>     -- 
>     -- Vania Joloboff
>
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
-- Vania Joloboff
LIAMA European Director
Also International Project FORMES
INRIA-CNRS-CAS SIAT--Tsinghua University
Tel +86 135 1063 1405