On Fri, 2020-04-24 at 13:03 -0600, Maurice Smulders via Gcc wrote:
> Hello,
>
> Hugo Landau figured out why it didn't load:
> Yes.
>
>
> The reference to cp_global_trees appears to be caused by the below
> code,
> which only relates to C++. For C, try commenting it out like this:
>
> OUTF ("- !compex/method\n", i);
> OUTF (" name: %s\n", method_name);
> OUTF (" asm: %s\n", mangled_name);
> #if 0
> _bool(" virtual", DECL_VIRTUAL_P(arg));
> _bool(" artificial", DECL_ARTIFICIAL(arg));
> _bool(" const", DECL_CONST_MEMFUNC_P(arg));
> _bool(" static", DECL_STATIC_FUNCTION_P(arg));
> _bool(" constructor", DECL_CONSTRUCTOR_P(arg));
> _bool(" destructor", DECL_DESTRUCTOR_P(arg));
> _bool(" copyconstructor", DECL_COPY_CONSTRUCTOR_P(arg));
> _bool(" baseconstructor", DECL_BASE_CONSTRUCTOR_P(arg));
> _bool(" completeconstructor",
> DECL_COMPLETE_CONSTRUCTOR_P(arg));
> _bool(" completedestructor",
> DECL_COMPLETE_DESTRUCTOR_P(arg));
> _bool(" operator", DECL_OVERLOADED_OPERATOR_P(arg));
> _bool(" castoperator", DECL_CONV_FN_P(arg));
> _bool(" thunk", DECL_THUNK_P(arg));
> _bool(" nothrow", TYPE_NOTHROW_P(TREE_TYPE(arg)));
> #endif
>
> However, trying to run it on a C file like
>
> struct __attribute__((compex_tag("x" foo { int x; };
> int main(int argc, char **argv) { return 0; }
>
> results in a segfault at this line in `_finish_type`:
>
> const char *struct_name = decl ?
> IDENTIFIER_POINTER(DECL_NAME(decl)) : NULL;
>
> It appears that the pointer DECL_NAME(decl) is corrupt,
Maybe DECL_NAME(decl) is NULL?
> but I can't
> figure out why that is. I'm no expert on writing GCC plugins and this
> was an amateur attempt, I'm not sure I ever tested it with C.
>
> But it still has a problem...
>
> Has this functionality been used for the C compiler, if not, how can
> I
> debug this the easiest way?
Yes, plugins do work with cc1 (I first got into GCC development by
writing plugins, and most of my work was on analyzing C code)
I wrote a guide to debugging GCC which you may find helpful:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
FWIW it's possible to write a plugin that will work with both the C and
C++ frontends while accessing FE-specific things like cp_global_trees
without rebuilding, by using weak symbols. This is something of a
hack, but I've used it successfully in a few places in my gcc-python-
plugin. See e.g.:
https://github.com/davidmalcolm/gcc-python-plugin/blob/master/gcc-python-tree.c#L51
for an example of using decl_as_string from the C++ FE if available,
and it being NULL in other FEs.
Hope this is helpful; good luck.
Dave
>
> Kind regards,
>
> Maurice Smulders
>
> On Fri, Apr 24, 2020 at 9:17 AM Maurice Smulders
> wrote:
> > Hello,
> >
> > Is it possible to make plugins for the C compiler (not the C++)
> > compiler? I was trying the (old) sample code at
> > https://github.com/hlandau/compex to make a plugin, but the plugin
> > only works with C++. when trying to use the C compiler it complains
> > about
> >
> > gcc -fplugin=/usr/local/lib/compex_gcc.so -D__COMPEX__=1
> > -fplugin-arg-compex_gcc-o=test_c.compex -o test_c test_c.c
> > cc1: error: cannot load plugin /usr/local/lib/compex_gcc.so
> >/usr/local/lib/compex_gcc.so: undefined symbol: cp_global_trees
> >
> > Is the mechanism differently, or are plugins even supported on the
> > C compiler?
