On Wed, Nov 30, 2011 at 02:54:26PM -0700, Tom Tromey wrote:
> 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 gues
> "David" == David Malcolm 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 thin
On Wed, 2011-11-30 at 15:06 -0500, David Malcolm wrote:
[...snip...]
> Any thoughts on how to address this? Are there any other approaches
> I've missed?
Answering my own question, Dave Korn pointed out in another thread:
http://gcc.gnu.org/ml/gcc/2011-01/msg00310.html
that one can use dlsym()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/30/11 13:06, David Malcolm wrote:
> Any thoughts on how to address this? Are there any other
> approaches I've missed?
Does print_decl do what you need?
jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG
On Wed, Nov 30, 2011 at 15:06, David Malcolm wrote:
> Any thoughts on how to address this? Are there any other approaches
> I've missed?
Why not use a langhook? We do this for lang_hooks::decl_printable_name.
Diego.
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 dynamical
