This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gcc-c-api


After a hiatus, I've restarted work on an API for GCC plugins -
specifically, a C API (given that my plugin is written in C, I have more
interest in that than a C++ API).

BTW, how many other GCC plugins are written in C?

It's still a work-in-progress, but can be seen here:

http://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/gcc-c-api?h=proposed-plugin-api

i.e. within the "proposed-plugin-api" branch of the gcc-python-plugin,
within the "gcc-c-api" subdirectory.  I've been gradually porting the
python plugin to use the proposed API, rather than poking at GCC's
insides itself.  I've also tried to follow the GNU coding conventions
within that directory (the plugin itself follows the Python coding
conventions).  I haven't done the copyright assignment paperwork yet.

There are no explicit test cases yet, though the python plugin's test
suite passes, exercising the code indirectly.

The API has a build-time dependency on Python (parts of it are
autogenerated, and Python is my natural choice for this work).  There
isn't a runtime dep though.

I started thinking about trying to create a patch to merge the API into
the GCC source tree, but I'm running into some high-level issues: how is
a plugin meant to actually use this API without requiring the use of an
in-development version of GCC?  Similarly, as a plugin author, I want my
plugin to be usable against GCC 4.6 onwards, but GCC's internal APIs are
gradually changing.  I see a lot of #ifs in my future, and it makes
sense to try to isolate the compatibility shims in one place, rather
than having every plugin author maintain them.

Given that, it's most useful, I think, if the API code can somehow be
used independently of GCC: perhaps it's more of a compatibility shim
that hides the differences between GCC versions (e.g. C vs C++ name
mangling, C++ internals in 4.8 onwards etc) and provides a stable ABI
(that way you only have to recompile the API implementation when
recompilng GCC: all plugins built against the API should remain
compatible - that's the goal, after all).

I'm not sure exactly how this is to be structured: external project vs
internal to gcc's source tree, but given that this is a non-trivial
amount of code and that I want it to support gcc 4.6, perhaps external
to the gcc source tree is the way to go.

Thoughts?

Hope this is helpful
Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]