[LLVMdev] Undefined symbol when loading pass

[Will Dietz]

Hi again,

Firstly, thanks to "Reid" from the llvm IRC, he was rather helpful in
resolving this issue.

For everyone's benefit, I'll explain the solution (and the problem in
slightly more detail).

Essentially it would appear plugins are (indeed) tasked with only
containing symbols for the code they use and explicitly not those the
tool loading them already uses.  In my example, I needed
Triple::Parse, but couldn't just link in all of LLVMSupport because
then wonky things happen since opt has it's own definitions for many
of symbols in LLVMSupport.

The solution is to just explicitly link against exactly the *.o's that
contain the pieces you need and nothing more.

To be completely clear, in my case:

LDFLAGS = $(LLVM_OBJ_ROOT)/lib/Support/$(BuildMode)/Triple.o

Fixed things up.

If you can't do this on a *.o granularity, more linking magic is
required, and if you want your plugin to work in multiple tools (which
each presumably have different subsets of the LLVM symbol set) you
might end up creating tool-specific plugins that contain the proper
symbols.  Or ship your own version of the tools that link your plugin
in directly.  Or something less crazy I'm not thinking of.

Anyway, hopefully that helps someone else who might run into a similar
situation :).

Thanks all,

~Will

On Wed, Jun 16, 2010 at 8:17 PM, Will Dietz <willdtz at gmail.com> wrote:
> Hi all,
>
> I'm running into a problem with building a pass from an external
> project and then loading it in opt.
>
> I'm making use of "Triple" in my pass, to detect the architecture
> we're building for.
>
> Triple is part of the LLVMSupport component...
>
> Anyway, my problem is this:
>
> --if I don't add 'support' to LINK_COMPONENTS, opt bails claiming it
> doesn't have a definition for Triple::Parse when loading the pass.
> --if I do link in LLVMSupport, the pass runs, but opt is unhappy
> because various commandline options are defined twice (presumably by
> opt's copy of pieces of llvmsupport).  The pass does seem to run as
> expected however, but spitting out errors isn't desired behavior...
>
> This would go away I think if my pass wasn't loaded dynamically and
> was built into opt, but that's not really an option presently.
>
> Is there some other/better way to build this, or any suggestions you might have?
>
> Thanks for your time,
>
> ~Will
>