llvm dev - Jun 2006 - [LLVMdev] Heads Up: libLLVMCore.a and loadable modules

There are some bugs against it that state the current progress. The
problem is that it depends on how the libraries are being used. Even if
you get past the linking problems, you will end up with re-registration
of passes and options, etc., which causes asserts.  So, for now, there
aren't many good solutions.

Reid.

On Thu, 2006-06-22 at 17:21 -0500, John Criswell wrote:
> Has anything been done about this issue since Reid first mentioned it?  
> I think I'm getting bitten by it.
> 
> -- John T.
> 
> Reid Spencer wrote:
> 
> > The recent change in the library structure to make libLLVMCore.a
instead
> > of LLVMCore.o has caused a little fallout. The problem is LLVM tools
> > that take a --load option to load a module dynamically may now cause
> > those modules to fail to load at runtime. This occurs because the tool
> > with the --load option might not be linking in all of libLLVMCore.a,
but
> > only the object modules actually needed by that tool. Consequently, a
> > module that uses something not linked into the tool will fail to link
at
> > runtime loading.
> >
> > For example, Yorion experienced this problem when he wrote a shared
> > library module that depends on DbgStopPoint which is in
> > IntrinsicInst.cpp.  His module links fine, but when it is loaded into
> > "opt" it fails to resolve the DbgStopPoint symbols he uses.
That's
> > because the opt program doesn't use DbgStopPoint and so those
symbols
> > are now missing because opt linked with libLLVMCore.a instead of
> > LLVMCore.o. 
> >
> > Simply linking the shared library module with libLLVMCore. a
doesn't
> > help because then you get things like AsmWriterPass being registered
> > multiple times (once from opt and once from the shared lib being
> > loaded).
> >
> > The only solution Yorion and I found was to copy the IntrinsicInst.cpp
> > code out of lib/VMCore and into his own area where it could be
compiled
> > and linked directly into his module.
> >
> > There may be other things that are not linked into tools like opt any
> > more that might cause similar problems for loadable modules. 
> >
> > I'll file a PR on this.
> >
> > Reid. 
> >   
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060622/e3469ef2/attachment.sig>

Reid Spencer wrote:
>There are some bugs against it that state the current progress. The
>problem is that it depends on how the libraries are being used. Even if
>you get past the linking problems, you will end up with re-registration
>of passes and options, etc., which causes asserts.  So, for now, there
>aren't many good solutions.
>  
>
Is it possible to link opt and analyze with VMCore.o and use libVMcore.a 
with everything else?

Also, do you know the PR# for the issue or the topics of any threads 
about it?  I get the feeling I'm asking a lot of already asked questions.

-- John T.
>Reid.
>
>On Thu, 2006-06-22 at 17:21 -0500, John Criswell wrote:
>  
>
>>Has anything been done about this issue since Reid first mentioned it?  
>>I think I'm getting bitten by it.
>>
>>-- John T.
>>
>>Reid Spencer wrote:
>>
>>    
>>
>>>The recent change in the library structure to make libLLVMCore.a
instead
>>>of LLVMCore.o has caused a little fallout. The problem is LLVM tools
>>>that take a --load option to load a module dynamically may now cause
>>>those modules to fail to load at runtime. This occurs because the
tool
>>>with the --load option might not be linking in all of libLLVMCore.a,
but
>>>only the object modules actually needed by that tool. Consequently,
a
>>>module that uses something not linked into the tool will fail to
link at
>>>runtime loading.
>>>
>>>For example, Yorion experienced this problem when he wrote a shared
>>>library module that depends on DbgStopPoint which is in
>>>IntrinsicInst.cpp.  His module links fine, but when it is loaded
into
>>>"opt" it fails to resolve the DbgStopPoint symbols he
uses. That's
>>>because the opt program doesn't use DbgStopPoint and so those
symbols
>>>are now missing because opt linked with libLLVMCore.a instead of
>>>LLVMCore.o. 
>>>
>>>Simply linking the shared library module with libLLVMCore. a
doesn't
>>>help because then you get things like AsmWriterPass being registered
>>>multiple times (once from opt and once from the shared lib being
>>>loaded).
>>>
>>>The only solution Yorion and I found was to copy the
IntrinsicInst.cpp
>>>code out of lib/VMCore and into his own area where it could be
compiled
>>>and linked directly into his module.
>>>
>>>There may be other things that are not linked into tools like opt
any
>>>more that might cause similar problems for loadable modules. 
>>>
>>>I'll file a PR on this.
>>>
>>>Reid. 
>>>  
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>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
>>    
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>LLVM Developers mailing list
>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>    
>>

On Thu, 2006-06-22 at 18:45 -0500, John T. Criswell
wrote:
> Is it possible to link opt and analyze with VMCore.o and use libVMcore.a 
> with everything else?
Yes, that's possible. It helps, but its not sufficient. There are things
in lib/System and lib/Analysis and lib/Support that get used by loaded
modules as well.
> Also, do you know the PR# for the issue or the topics of any threads 
> about it?  I get the feeling I'm asking a lot of already asked
questions.
:)

http://llvm.org/bugs/show_bug.cgi?id=780

Reid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060622/12808fbf/attachment.sig>