[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Questions on exported plugin headers: minimal or full?
From:       Basile STARYNKEVITCH <basile () starynkevitch ! net>
Date:       2009-06-30 15:16:06
Message-ID: 4A4A2C36.4060109 () starynkevitch ! net
[Download RAW message or body]

Hello All,

This discussion is triggered by the one-line patch 
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02227.html (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/Makefile.in (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 
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02227.html  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).

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
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} ***

[prev in list] [next in list] [prev in thread] [next in thread]