[LLVMdev] [patch] OrcJIT and weak symbols

[Lang Hames]

Hi Axel,

Sorry about the delay in checking this out. I'm working through my review
backlog - Keno's weak symbol patch is next on the list, then this.

- Lang.

On Fri, Feb 6, 2015 at 3:36 AM, Axel Naumann <Axel.Naumann at cern.ch> wrote:

> Hi Keno and Lang,
>
> I'm currently test driving cling with the OrcJIT - your r227228 is
> obviously crucial there, too.
>
> I needed the attached patch on top, else I had symbols emitted (bumping
> up UnfinalizedSections) without a corresponding NotifyFinalizedT call
> because the symbol could not be found by
> LazyEmittingLayer::EmissionDeferredSet::Search()'s call to
> B.lookupSymbolAddressIn() and thus the ObjectHandle was never finalized.
>
> I think it would be good to assert that an Emit()ed ObjectHandle is also
> finalized - this seems to be a fairly fundamental assumption e.g. for
> the Orc MCJIT replacement.
>
> I'm not sure how to create a simple test for this, though. Please let me
> know whether my description allows you to do that or whether I need to
> spend more time in reducing our test cases...
>
> Cheers, Axel
>
>
> On 13.01.2015 17:07, Keno Fischer wrote:
> > Hi Axel.
> >
> > I put up a patch at http://reviews.llvm.org/D6950. Have a look and see
> > if it works for you.
> >
> > Thanks,
> > Keno
> >
> > On Tue, Jan 13, 2015 at 9:44 AM, Axel Naumann <Axel.Naumann at cern.ch
> > <mailto:Axel.Naumann at cern.ch>> wrote:
> >
> >     Hi Keno,
> >
> >     The part that scares me a bit is
> >
> >     > and then adjust the other methods to not
> >     > bail out two quickly when encountering a weak symbol.
> >
> >     I would very much appreciate if you could implement this; I don't
> have
> >     enough knowledge of the MCJIT nor llvm CodeGen internals... I will
> >     happily try it out and provide you with feedback, though! :-)
> >
> >     Thank you *so* much for your fast reaction!
> >
> >     Cheers, Axel
> >
> >
> >
> >     On 13.01.2015 00:30, Keno Fischer wrote:
> >     > Hi Axel,
> >     >
> >     > the problem is that weak symbols are not handled in RuntimeDyld at
> all.
> >     > The proper solution is probably to add a separate case for weak
> symbols
> >     > (where we're already taking care of common symbols) in
> >     > RuntimeDyld::loadObjectImpl and then adjust the other methods to
> not
> >     > bail out two quickly when encountering a weak symbol.
> >     >
> >     > Please let me know if you're planning to work on a patch for this,
> >     > otherwise I'll have a go tomorrow.
> >     >
> >     > Thanks,
> >     > Keno
> >     >
> >     > On Mon, Jan 12, 2015 at 11:45 AM, Axel Naumann <
> Axel.Naumann at cern.ch <mailto:Axel.Naumann at cern.ch>
> >     > <mailto:Axel.Naumann at cern.ch <mailto:Axel.Naumann at cern.ch>>>
> wrote:
> >     >
> >     >     Hi,
> >     >
> >     >     I'm finally moving cling to MCJIT - and MCJIT is wonderful! So
> >     far I
> >     >     only ran into this issue:
> >     >
> >     >     $ cat linkonceodr.cxx
> >     >     extern "C" int printf(const char*,...);
> >     >
> >     >     template <class T> struct StaticStuff {
> >     >       static T s_data;
> >     >     };
> >     >     template <class T> T StaticStuff<T>::s_data = 42;
> >     >
> >     >     int compareAddr(int* mcjit);
> >     >
> >     >     #ifdef BUILD_SHARED
> >     >     int compareAddr(int* mcjit) {
> >     >       if (mcjit != &StaticStuff<int>::s_data) {
> >     >         printf("Wrong address, %ld in shared lib, %ld in mcjit!\n",
> >     >                (long)&StaticStuff<int>::s_data, (long)mcjit);
> >     >         return 1;
> >     >       }
> >     >       return 0;
> >     >     }
> >     >     #else
> >     >     int main(int, char**) {
> >     >       return compareAddr(&StaticStuff<int>::s_data);
> >     >     }
> >     >     #endif
> >     >
> >     >
> >     >     $ clang++ -fPIC -shared -DBUILD_SHARED -o liblinkonceodr.so
> >     >     linkonceodr.cxx
> >     >     $ clang++ -emit-llvm -c linkonceodr.cxx -o - |
> >     >     LD_PRELOAD=./liblinkonceodr.so lli -
> >     >     Wrong address, 140449908087496 in shared lib, 140449908076544
> >     in mcjit!
> >     >
> >     >
> >     >     I.e. while compareAddr is resolved from the dylib, this:
> >     >
> >     >     @_ZN11StaticStuffIiE6s_dataE = linkonce_odr global i32 42,
> align 4
> >     >
> >     >     is not: it is re-emitted by the MCJIT. When building a binary
> and
> >     >     linking against that dylib, _ZN11StaticStuffIiE6s is correctly
> >     picked up
> >     >     from the dylib. I would expect MCJIT to behave the same.
> >     >
> >     >     I'll try to fix that myself, but I'd appreciate a hint where
> >     to do that.
> >     >     Should I collect linkonce_odr-s and "replace" their emitted
> >     code as part
> >     >     of llvm::RuntimeDyldImpl::resolveRelocations()? Or is this
> just a
> >     >     missing case somewhere?
> >     >
> >     >     That's e.g. with
> >     >
> >     >     $ lli --version
> >     >     LLVM (http://llvm.org/):
> >     >       LLVM version 3.6.0svn
> >     >       Optimized build.
> >     >       Built Jan 12 2015 (10:52:59).
> >     >       Default target: x86_64-unknown-linux-gnu
> >     >       Host CPU: corei7-avx
> >     >
> >     >
> >     >     Cheers, Axel.
> >     >
> >     >
> >     >     _______________________________________________
> >     >     LLVM Developers mailing list
> >     >     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
> >     <mailto:LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>>
> >     >      http://llvm.cs.uiuc.edu
> >     >     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >     >
> >     >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150217/8b3f547d/attachment.html>