This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: using plugin and lto: problem linking c-pragma symbol
- From: Joern Rennecke <amylaar at spamcop dot net>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Basile Starynkevitch <basile at starynkevitch dot net>, Diego Novillo <dnovillo at google dot com>, Pierre Vittet <piervit at pvittet dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 01 Jun 2011 09:57:24 -0400
- Subject: Re: using plugin and lto: problem linking c-pragma symbol
- References: <4DE3BD83.6060702@pvittet.com> <BANLkTi=Q_Y98meB_Lu5bT+DEwp6bLJiSKQ@mail.gmail.com> <20110530194406.b8e9a454.basile@starynkevitch.net> <BANLkTin+cDhtnDwjPFN=S4Wqz+zeFC1Sfw@mail.gmail.com> <20110530231839.0d8d0eeb.basile@starynkevitch.net> <BANLkTimhTPy1APxX40fTCMi3J+u6Ljf=Hg@mail.gmail.com> <20110531191705.21934344.basile@starynkevitch.net> <BANLkTimH+sh+08+bYx8g+qcm_Kw44P2W4A@mail.gmail.com>
Quoting Richard Guenther <richard.guenther@gmail.com>:
Iff we want to make plugins not randomly fail with -flto (which I
think we _do_ want) then it is the plugin loader machines job
to check for compatibility and either ignore (in case of lto1 maybe)
or reject (in other cases) the plugin. So, I don't think a single MELT
plugin that works with all frontend and at the same time has access
to all frontend functions can work. If it could then we would have
not 5 different frontend executables but a single one.
Huh? That does not follow. The access to frontend functions doesn't
have to be direct. The weak function approach with wrapper and
null pointer check is already mare expensive that a straight forward
function call, anyway.
As you stated before, the plugin can access front end functions via
language hooks and/or function pointers that have been initialized with
the use of dlsym.
Plus, if you have all such function pointer initializations in one place,
that makes a nice check-list of functionality to potentially propose for
new language hooks.