tools only pull in some symbols from library archive

[nlewycky]

Bugzilla Link	780
Resolution	FIXED
Resolved on	Mar 30, 2008 12:55
Version	1.0
OS	All
CC	@lattner

Extended Description

At the moment, the tools link against libLLVM*.a and pull in only the symbols
they need. The problem comes when loading .so files that also depend on symbols
from libLLVM*.a. If the .so is not linked with the .a then it will be missing
symbols.

The alternative, linking to the .a doesn't quite work either. You will get the
RegisterAnalysis or RegisterOpt in duplicate, triggering various errors:

$ analyze -load=./hypothesis.so -hypothesis hypo1.l
analyze: CommandLine Error: Argument 'track-memory' defined more than once!
analyze: CommandLine Error: Argument 'info-output-file' defined more than once!
analyze: CommandLine Error: Argument 'stats' defined more than once!
analyze: CommandLine Error: Argument 'debug' defined more than once!
analyze: CommandLine Error: Argument 'debug-only' defined more than once!
analyze: CommandLine Error: Argument 'help' defined more than once!
analyze: CommandLine Error: Argument 'help-hidden' defined more than once!
analyze: CommandLine Error: Argument 'version' defined more than once!
analyze: Pass.cpp:340: void llvm::RegisterPassBase::registerPass(): Assertion
`PassInfoMap->find(PIObj.getTypeInfo()) == PassInfoMap->end() && "Pass already
registered!"' failed.

The solution is probably to move from .a's to .so's. The other solutions include
making the .a's more fine-grained and changing the modules to explicitly allow
multiple entries.

[lattner]

To me, the right solution to this is probably to get rid of the last circular library dependency, then switch
to .o files for opt/analyze/bugpoint.

However, that gets tricky too, as we go back to "linking multiple versions of the same library".

What symbols are missing? Maybe we just need to add them to things like "Transforms/LinkAllPasses.h"?

In general, .a files without cyclic dependencies are the best way to distribute libraries... (IMHO)

-Chris

[llvmbot]

Here's what I see for potential solutions:

1. Incorporate all modules from an archive library into any LLVM tool that needs
   any symbol from that archive.
   Advantage: no link problems
   Disadvantage: bloated executables

2. Break up certain .a libraries into smaller pieces so the pieces conform to
   just what a given tool needs.
   Advantage: no link problems (or fewer, anyway)
   Disadvantage: major rework of LLVM directories or makefiles

3. Build shared objects (DLLs) that contain all the code from logical groupings
   of functionality. Make both user and LLVM tools link against these shared
   libraries. We could do this on a case-by-case basis. Tools such as llvm-as
   and llvm-dis which don't support -load might want to statically link
   everything so there is no runtime linking from a .so. Any app that does have
   -load would link against the shared lib library.
   Advantage: not link problems, saves memory when multiple LLVM programs
   running, resolves all the cyclic dependency problems as there are
   fewer things to link against.
   Disadvantage: slower loading times.

In all these choices, we should do at least three things in conjunction with
any of them:

1. Resolve circular dependencies so that there is a simple tree of dependencies
2. Strictly control what's public and what's not. There might be some things
   exposed as external symbols that should not be.
3. Provide as much choice and as few roadblocks as possible for the end user.

Reid.

[lattner]

#​1 is basically "use relinked .o's for everything". As you say, badness...

#​2 is impossible in general, because there are more llvm tools in the world than just those in mainline
CVS, and no single person probably knows about all of them. :)

#​3, as you mention, will lead to REALLY slow load times, on the order of our current link times. I don't
think this is acceptable.

However, note that this problem is just for tools that have -load options. Things like gccas/gccld don't
have this problem, and using minimal .a files is really good for them.

As such, I propose #​4:

4. Make the headers which are designed to suck in all symbols related to opts/analyses do their job.
   Continue to use these headers for opt/analyze/bugpoint.

-Chris

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#800 has been marked as a duplicate of this bug. ***

[llvmbot]

Mine.

[llvmbot]

Here are some initial commits in resolution of this bug:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035424.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035425.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035426.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035427.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035428.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035429.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035432.html

[llvmbot]

This bug is resolved with all the patches between:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035435.html

and

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060605/035448.html

[llvmbot]

Nick,

Althought I'm fairly confident this fix will work (because I checked linker maps
to determine what was included in the executable), could you please verify that
this problem fixes your situation and mark this bug verified if it does.

Thanks,

Reid.

[llvmbot]

Unfortunately, resolving the libLLVMCore references didn't solve the whole
problem. There are now unresolved symbols for lib/Support and lib/System.

The solution is to enhance lib/Support, lib/System, their corresponding header
files and the LinkAllVMCore.h header file to ensure that all of lib/Support,
lib/System, and lib/Support/bzip2 are incorporated. Then, a particular shared
lib loadable by analyze or opt should not link with any of those libraries nor
VMCore but let the symbols be resolved at runtime from the symbols in the
executable.

Maybe we should revisit the shared library idea?

[lattner]

shared libraries are a cop-out. The major issue here is that we don't have a well-defined interface for
plugins are allowed to use. What parts of libsupport aren't getting pulled in right?

[llvmbot]

SlowOperationInformer for one.

[nlewycky]

add more files to LinkAllVMCore
This patch adds the minimum files necessary to make my program load. However,
it pulls in too much as I get an error with duplicate registered passes in the
pass manager.

[llvmbot]

I'm really not sure what to do about this situation. We can now selectively link
what's needed, but that's only 1/2 the problem. The registrations of passes/etc.
should probably be separated into separate files, or possibly duplicate
registration should just be ignored.

Any ideas?

[llvmbot]

Nick, your patch has been committed, more or less. I had to work around a
problem that caused a dependency cycle between lib/Support and lib/System. We're
trying to eliminate dependency cycles from LLVM.

This still isn't finished. The rest of lib/System needs to be included, as well
as more of lib/Support.

[llvmbot]

All of lib/System is now available to loaded modules. The programs that #include
LinkAllVMCore.h will automatically link all of lib/System.

This was the easy part. What's a little more difficult is whether all of
lib/Support should also be included in such programs. My inclination is to just
do that, although it will (slightly) increase the size of the programs.

These patches were applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060724/036175.html
through
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060724/036185.html