This is the mail archive of the 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]

Re: gcc extensibility

Le 29 mars 2012 à 15:14, Richard Guenther a écrit :

> On Thu, Mar 29, 2012 at 2:34 PM, Niels Möller <> wrote:
>> I originally wrote this email as a reply to Ian Lance Taylor on a
>> different list, and he suggested that I send it also to the gcc list.
>> Please cc me on replies, since I'm not subscribed to the list. I hope
>> I'm not being too off-topic or off-the-mark.
>> Let me write down some reflections on gcc extensibility, even if I'm not
>> familiar at all with gcc internals.
>> 1. I imagine the plugin API ought to stay in plain C, right?
>> 2. Then there are at least two ways to think about the plugin API to,
>>   e.g., the gcc tree abstraction.
>>   Either one can define a C API one think the plugins will like, and
>>   then implement that on top of the internal C++ interfaces. These will
>>   be small wrapper functions, which lets the internal interfaces evolve
>>   without affecting the plugins.
>>   Or one sticks to a single "unified" tree API, to be used *both*
>>   internally and by plugins.
>>   I suspect the second option is the right one, because it brings some
>>   equality between plugin authors and gcc developers. It should make it
>>   easier to adopt a plugin into gcc proper. Together with (1), this
>>   forces the internal interface to be C rather than C++, which I guess
>>   you may see as a serious disadvantage.
> On the contrary - I think the first option is the right one.  Only that way
> we can provide a stable ABI towards plugins.

I also think that the plugin layer should be as much as possible distinct from
the internals, may some patch break the plugin API for a short period of time
in the trunk, as soon as official releases keep it working well
(as i think plugins must not slow down GCC own evolution).

As plugins are only meant to perform introspection and minor tree transformations
they do not need the whole internal API. Such an API also require stability
contrary to internals which may change at any time. 

As a plugin developer, i don't think plugin developers should have
that equality with GCC developers you are worried about.

>>   Going for a unified API, one gets less independence between plugins
>>   and gcc internals, but in return, one gets less clutter, and I think
>>   it may improve quality. Otherwise, it seems likely that one ends up
>>   with an internal interface which is powerful but somewhat ugly
>>   (internal use only, right?) and an external interface which may be
>>   beautiful on the surface, but in practice it's a second class citizen
>>   and awkward for doing interesting things with.
> It really depends on what plugins should be doing.  Or rather what
> most plugins will end up doing.  In the end we probably will end up
> with a stable plugin API/ABI for that common case (introspection
> and simple instrumentation) and the awkward current one exporting
> every GCC internal.
>> 3. What is the purpose of the plugin API? I can see that it should make
>>   it easier to prototype new optimization passes. Both for educational
>>   purposes, and research, as well as by the gcc developers themselves.
> No.  That's way easier to do if you are _not_ a plugin.
>>   One of the goals you stated was "I think parts of GCC needs to move
>>   toward being a component of tools other than pure compilation, such
>>   as refactoring, profile analysis, debugging."
> Right, and I see primarily those uses.
> Richard.

Well currently GCC deeply lacks the structure to break it into distinct
component. I roughly see plugins as a solution in the middle : you keep
the whole gcc in a single block, but still you can perform minor task
on your own by dlopening a of your own rather than breaking
gcc in a proper structued libgcc.

Of course, a beautiful defined and structed libgcc would be welcome,
but this would take much more time refactoring the existing code base,
and see, plugins which are only a small part of that work, are already
tough to implement.

Romain Geissler

>>   I think we can all agree that's highly desirable. To be more
>>   concrete, I think it would be useful have access to information from
>>   the parse tree, from the symbol table (both for compiler and linker),
>>   dataflow analysis, etc, when editing C code in emacs. Is a plugin API
>>   the right tool for that type of integration? Or should one also have
>>   a gcc library, and have various other specialized tools link to that
>>   library?
>>   Maybe the organization of valgrind could provide some inspiration,
>>   with a couple of different tools on top of the same machinery.
>> Happy hacking,
>> /Niels
>> --
>> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
>> Internet email is subject to wholesale government surveillance.

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