On Wed, 1 Jun 2011 11:18:16 +0200
Richard Guenther <richard.guent...@gmail.com> wrote:
> On Wed, Jun 1, 2011 at 6:03 AM, Basile Starynkevitch
> <bas...@starynkevitch.net> wrote:
> > On Tue, 31 May 2011 23:52:11 +0200
>
> I don't remember saying no to both. I don't see how the invoking_program
> would fix anything (you have that by looking at lang_hooks.name).
Alternatively, the same name can be found by the progname variable
which is bizarrely defined in gcc/diagnostic-core.h, bizarrely because
while it understandable that diagnostic messages might perhaps
sometimes print which program are emitting them, the knowledge of the
program name has nothing to do with diagnostics (in other words, a
newbie won't look first into diagnostic-core.h if he wanted to get the
argv[0] of main).
And I still believe that knowing the name of the executable might help
plugins, because precisely a plugin invoked from lto1 would not do
front-end things, and some strange people (me included) would want to
code their plugins usable from various programs (cc1, cc1plus, lto1),
at least in the sense that the same -fplugin=name argument work for
gcc, g++, ... with and without -flto
I cannot understand why both progname and lang_hooks.name exist, if
they always have the same value (I did not check if it is the case). If
really they have the same value, and if any GCC code (in particular
plugins) can access it both ways, I don't understand why we keep both
of them.
This brings a question (which seems to me related to the mythical
modularization of GCC): what is the most important global variable,
lang_hooks or progname. Which one should be removed (I would imagine
that progname is less important than lang_hooks)?
> The print-file-name does not handle the much more common case
> of plugins that work with (any) middle-end - those would not need
> different .so files.
It surely could. We could imagine a patch which, for gcc -fplugin=name
running cc1, look first for
`gcc -print-file-name=plugin`/cc1/name.so
and else (if that .so file is not found) in
`gcc -print-file-name=plugin`/name.so
likewise, for g++ -fplugin=name running cc1plus, look first for
`gcc -print-file-name=plugin`/cc1plus/name.so
and else (if that .so file is not found) in
`gcc -print-file-name=plugin`/name.so
and when lto1 is started (by gcc or g++), it would look first for
`gcc -print-file-name=plugin`/lto1/name.so
and else (if that .so file is not found) in
`gcc= -print-file-name=plugin`/name.so
My feeling is that such trick still permit plugins invoked with
-fplugin=name to work reliably. The burden on the plugin's author would
be to deliver his plugin as three different shared objects name.cc1.so
name.cc1plus.so name.lto1.so (which might be built from different
plugin source files) and have his installation procedure doing things
similar to
install name.cc1.so `gcc -print-file-name=plugin`/cc1/name.so
install name.cc1plus.so `gcc -print-file-name=plugin`/cc1plus/name.so
install name.lto1.so `gcc -print-file-name=plugin`/lto1/name.so
In the case name.cc1.so is the same as name.cc1plus.so the installation
procedure could install symlinks.
Of course, such complex things would only be needed for plugins complex
enough to provide both front-end & middle-end processing.
Most of the simpler middle-end only plugins would simply be built as
one single variant and be installed with
install name.so `gcc -print-file-name=plugin`/name.so
And with the path I have imagined would work as previously.
>
> >>
> >> 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.
> >
> > I'm ok with having different melt*.so for various situations, as long
> > as the naive user only gives the same -fplugin=melt argument.
> >
> > But I still don't understand concretely what you mean, in other words
> > what kind of solution to you want.
>
> Well, I don't have a fully designed solution for your melt problem.
Actually, I don't need a fully designed solution for MELT only. I know
that whatever interface is documented [and the point is that gcc -flto
-fplugin=pragma_plugin fails in an undocumented way in the
pragma_plugin.c test file is compiled and installed as a plugin!] &
implemented, I would be able to make horrible tricks in MELT to make it
nearly work.
What I was asking is a more general question for plugins (not only
MELT). Either we just speak of plugins (as we did for 4.5 & 4.6), or we
explicitly speak of front-end plugins & middle-end plugins and
*document* that, and give them different interfaces (perhaps even
different user options, like -ffront-end-plugin=name &
-fmiddle-end-plugin=name...)
> But the direction we need to walk to is to make plugin authors
> label their plugin (in some way, for example by a global enum symbol)
> whether it works for any frontend or only a specific frontend.
My proposal of installing them in `gcc -print-file-name=plugin`/cc1/ or
in `gcc -print-file-name=plugin`/lto1/ is another way to "label"
plugins, by their installation directory.
I don't see it much different that a global enum symbol.
> Then
> it's easy to diagnose/ignore those plugins at load time (and solve
> the -flto problem). The MELT issue is entirely different (and more
> complicated) I think. With RTLD_LAZY MELT could just avoid
> calling into the "wrong" functions and it would work (but it can't
> check for availability of symbols other via dlsym, it has to know
> it in advance, for exampel by looking at lang_hooks.name).
>
> > Do you think (as I do) that it is bad for any short plugin option like
> > -fplugin=name
> > (i.e. the case when we don't give a full path ending with .so)
> > be running well when invoked as
> > gcc -fplugin=name -O2 foo.c bar.c -o prog
> > and be failing when invoked as
> > gcc -fplugin=name -flto -O2 foo.c bar.c -o prog
> > with a message the naive user don't even understand?
>
> Yes, I agree that's bad, and I agreed so in previous mail. Making
> GCC symbols weak is the solution you proposed and that is not
> acceptable.
>
> > What solution do you propose to that issue? I suggested some, but you
> > (Richard) said no to all of them, instead vaguely suggesting more
> > language hooks. But I don't concretely understand what sort of patch
>
> You are really annoying when you claim this sort of things. If you can't
> deal with my technical complaints then I can't do anything about that.
> You also can't expect me to solve your problems - after all I have no
> personal interest in MELT (or plugins in general). If I give you directions
> then that's because I'm trying to be constructive and not only the
> nay-sayer you claim I am (maybe that I have to say no to most of
> your proposals isn't because I say something but because of your
> proposals?).
>
> > you want ... Are you thinking of replacing every occurrence of
> > pragma_lex with e.g. some new field in struct lang_hooks_for_decls
> > inside gcc/langhooks.h ? Or what precisely?
>
> No, I didn't give you concrete advise for your problem but a general
> one that for plugins it might make sense to expose _some_ frontend
> specifics via langhooks.
>
> > You also told us
> >
> >>> Instead we need to expose a defined set of functions and structures,
> >>> and we can easily provide them through indirect dispatch (which opens
> >>> the possibility for a stable API even when the internal API changes - to
> >>> some extent at least).
> >
> > I agree in principle, but who will define and how will be defined that
> > mythical stable API? In my view, you are talking of the mythical
> > ModularGCC project, which should be a mega-patch, and I never saw it on
> > gcc-patches@ so far.
>
> Well, I didn't agree with the way plugins got into GCC without a defined
> set of exposed functions. That remark was in that direction.
>
> With MELT you are essentially not developing a plugin but developing
> a GCC abstraction layer to be used by plugins. That's compeltely
> out of the scope of what a plugin should do (IMHO). Now you are
> there, and as MELT is essentially a whole cc1 (or cc1plus) it has
> to live with the same restrictions cc1 (or cc1plus) has. Which means
> that ideally instead of doing gcc -plugin=MELT and have it work for
> all frontends and lto you go the way cc1 (or cc1plus) goes and
> dispatch via your own driver! 'Melt -c t.c' would then magically detect
> the language and add the correct .so to the -plugin argument.
>
> >
> > What is practically the stable API you are dreaming of?
> > What are the set of C names inside it?
>
> I don't know. What I would suggest is build GCC with
> -fvisibility=hidden and then see what complaints come from
> plugin developers and 1) add those symbols explicitly that we
> think are ok to export, 2) wrap those we don't want to export
> but need in some form in a plugin-api.[ch].
This is not a valid answer. A *stable* API should be agreed upon,
*documented* as such, and have coding conventions. What you suggest is
just a way to discover which symbols are used by some particular
plugin. It does not define a stable API. By coding conventions, I am
dreaming in particular of naming conventions (inspired by GTK practice
or C++ namespaces) such as all C front-end functions have names
starting with ccfe_, all C++ front-end functions are starting with
cpfe_, all common C-family front-end functions are starting wirth
cffe_, all middle-end functions are starting with gme_ etc... We are
extremely far from such a stable API, so I don't believe it will happen
soon (and I could even imagine gcc becoming marginally used before that
happens).
A stable API is an interesting platonic wish, but I don't think it will
happen for 4.7. And so far, I did not observe patches going in that
direction.
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 mine, sont seulement les miennes} ***
