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]

Questions on exported plugin headers: minimal or full?

Hello All,

This discussion is triggered by the one-line patch (I might have already written some email on this in a different way). I believe it has been at least informally discussed at the GCC summit a few weeks ago (which I was not able to attend). So probably I am asking questions about what has been already settled there!

I believe that the PLUGIN_HEADERS should be as complete as possible. Alternatively, we might define a (small, strict, well-defined) subset of GCC functions which are supposed to be callable from plugins (and hence announcing a well defined GCC API) but I understood (at last year's summit) that we don't want to (because that would ease proprietary plugins) and that we are not able to define a stable GCC API (because there is no such a beast).

The current situation is quite unsatisfactory (but I am aware that plugins is still an experimental feature, and I am afraid that stage1 will close too soon to permit easy evolution!). A plugin writer may need some GCC header file which is not yet in the PLUGIN_HEADERS variable of gcc/ (I call these headers listed there exported headers). Hence, he either nearly always needs the entire source tree and build tree of GCC (and that is IMHO a very costly requirement, contradictory to plugins), or need (as I am trying to do) to push an additional file (i.e. a one line patch) into the trunk to write his plugin.

My belief is that a plugin writer could (if he wants to) invoke any function inside GCC which makes some sense at some occurrence of invoke_plugin_callbacks in the trunk source. If you agree with that, the plugin exported headers should contain every header included by every trunk file calling invoke_plugin_callbacks.

The point is to compute this set of files, or alternatively to decide that every GCC header should be exported.

If the host GCC compiler (ie the compiler which compiles GCC) is a recent version of gcc, we might have some trick using gcc -MD to determine this set. I did try something similar in the MELT branch, but for some reason it breaks when --enable-multilib is configured (or perhaps more generally on cross compilers).

Otherwise we need a strategy to decide what functions are *not* callable from a plugin.

My short opinion is that PLUGIN_HEADERS should contain every GCC header (but I don't know yet how to implement that). Do you agree on this goal? [the alternative is many one-line patches]

If we still agree that there is no stable API inside GCC, I don't see how we could avoid that. And the main argument against putting every header file in the exported header set seems to be disk space, which is not a big issue today (it seems to me that the total space of all GCC header files is about 30Mbytes).

My feeling is that having the PLUGIN_HEADERS set evolve by small one-line patches like is very frustrating. If stage1 closes soon (or is it already closed), that means that plugins won't be usable in gcc 4.5 but only later (ie in more that one year), because I would expect that PLUGIN_HEADERS won't be permitted to evolve in stage2 or stage3 (since increasing it is not a bug resolution).


email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

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