Working with frontend-specific aspects of GCC from a GCC plugin

[David Malcolm <dmalcolm at redhat dot com>]

I maintain gcc-python-plugin [1].  I'm hoping to expose the function
decl_as_string() from the C++ frontend from within my plugin.

Unfortunately, given that that symbol is defined within gcc/cp/error.c,
it is only defined within the C++ frontend: cc1plus.  This works OK when
my plugin is dynamically loaded from cc1plus.  However, if I add a call
to this function to my plugin, the plugin fails with a linker error if
loaded from other frontends that don't define that symbol.  For example,
trying to use such a plugin to compile C code fails with:

  cc1: error: cannot load plugin python.so
  python.so: undefined symbol: decl_as_string

I'm wondering what the best way of managing this situation is, and how
other plugin authors have approached this.

I can think of several approaches:
(a) split the plugin into a core component, plus frontend-specific
shared libraries, and dynamically load the appropriate shared library
when the plugin is loaded, based on which frontend is running.  If so,
how should the plugin best determine which frontend it's being invoked
from?  (it also slightly complicates installation, given that the extra
shared libraries need to be located by the plugin).

(b) somehow set things up within the ELF metadata or linkage flags so
that the symbols aren't immediately needed at dynamic-link time, and
make sure that they only ever get called from frontends that provide
them (and cross our fingers and hope that the missing functions are
never actually called).  Not yet sure if this is feasible.  Again, this
raises the question of how to determine what frontend we're a plugin
for.

(c) build the plugin multiple times, once per frontend, and somehow use
the correct version of the plugin.

(d) not expose that function, and somehow fake it using "core" GCC
functionality.  However that seems suboptimal: I'd prefer to expose rich
information to users of the plugin, and at some point frontend-specific
structures and APIs are probably going to be needed.

Any thoughts on how to address this?  Are there any other approaches
I've missed?

Thanks
Dave

[1] https://fedorahosted.org/gcc-python-plugin/