This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Working with frontend-specific aspects of GCC from a GCC plugin
- From: Tom Tromey <tromey at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 30 Nov 2011 14:54:26 -0700
- Subject: Re: Working with frontend-specific aspects of GCC from a GCC plugin
- References: <1322683614.2598.21.camel@surprise>
>>>>> "David" == David Malcolm <dmalcolm@redhat.com> writes:
David> I maintain gcc-python-plugin [1]. I'm hoping to expose the function
David> decl_as_string() from the C++ frontend from within my plugin.
I think this problem was discussed before, either here or on
gcc-patches, I forget.
David> (b) somehow set things up within the ELF metadata or linkage flags so
David> that the symbols aren't immediately needed at dynamic-link time, and
David> make sure that they only ever get called from frontends that provide
David> them (and cross our fingers and hope that the missing functions are
David> never actually called). Not yet sure if this is feasible. Again, this
David> raises the question of how to determine what frontend we're a plugin
David> for.
One idea that came up was to redeclare the FE-specific functions as
'weak', then check to see if they are available at runtime before
calling them. It seems like a pain to me, since you have to rewrite the
declarations, but I guess it could work. You could maybe write a plugin
to write out the declarations :)
Tom