Heads Up: libLLVMCore.a and loadable modules

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.

I think we should use the same solution that forces opt/analyze to link all of the passes out of the transformation .a files:
http://llvm.org/bugs/show_bug.cgi?id=800#c2

-Chris

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:

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.

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.

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.

:slight_smile:

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

Reid.