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.
2013/3/13 Vania Joloboff <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 http://llvm.cs.uiuc.edu
>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130313/ba8313f5/attachment.html>
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
On Wed, Mar 13, 2013 at 10:41 AM, Vania Joloboff <vania.joloboff at inria.fr>wrote:> 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 ? >Maybe. You can also annotate all the symbols you intend to use in the JITed code with __attribute__((visibility("default"))), which will make them visible to dlsym(). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130313/b0c2161b/attachment.html>