[LLVMdev] [patch] OrcJIT and weak symbols
Lang Hames
lhames at gmail.com
Tue Mar 10 18:32:01 PDT 2015
Hi Axel,
Sorry for the delay.
r231896 goes some way towards addressing this issue, but we need to thread
the new class (RuntimeDyld::SymbolInfo) through MCJIT and
RTDyldMemoryManager before we can really do what Keno wants. I'll put a
mail out on the list warning clients about the change - hopefully we can
get the ball rolling on this quickly.
Cheers,
Lang.
On Wed, Feb 18, 2015 at 11:10 AM, Lang Hames <lhames at gmail.com> wrote:
> 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/20150311/7fb5fb4e/attachment.html>
More information about the llvm-commits
mailing list