On Feb 2, 2009, at 9:15 PM, Mark Mitchell wrote:
Unless we have a lot more stability in plugin API than I expect we're
actually going to have at first, I suggest we check something like the
md5sum of the GCC binary itself. (Yes, I see the recursive problem in
building such a binary.) The chances that my plugin will work with
your
compiler seem near-zero, and the failure modes will be ugly.
But, plugins for a popular compiler binary (e.g., that associated
with a
GNU/Linux distribution, or with a compiler distribution) would make
sense.
The MD5 idea would hurt us because we have cc1 binaries compiled with -
O0 -g3 -gdwarf2 and with normal optimization, and swap them out on
occasion. In shops that deal with large source bases, I suspect this
is not unheard-of.
Our plugins do not break when switching compiler binaries. In fact, I
have had plug-in binaries that perform very simple tasks work fine
when switching (minor!) compiler releases.
Perhaps if there is an ICE or GCC issues a warning / error, GCC could
simply append "The plugin /path/to/plugin.so is not compatible with
this GCC" to the message. Alternatively, GCC could always complain
and you could have a flag -fforce-incompatible-plugins.
Since the contents of enum machine_mode change based on target, I
think it might be appropriate to check against the target as well as
the version number and vendor patch level. Is there anything else we
need to check?
Sean
