On Wed, Jun 1, 2011 at 6:03 AM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Tue, 31 May 2011 23:52:11 +0200 > Richard Guenther <richard.guent...@gmail.com> wrote: > [...] >> I don't see a strong need for cross-language plugins with >> frontend function access - "meta plugins" such as MELT >> may be an exception, but they have to deal with that >> in a similar way we deal with frontends - have MELT++, MELTC, >> MELTFortran, etc. > > Yes, but I really want MELT to remain usable with only the same > -fplugin=melt > argument in all cases: with or without -flto, for C or C++ or Fortran > etc... The naive user wants the same option in all situations > (languages, with or without -flto; with some extra > -fplugin-arg-melt-... defining the work he want MELT to do). > > My propositions of adding an invoking_program in struct > plugin_gcc_version in http://gcc.gnu.org/ml/gcc/2011-05/msg00324.html > and of having -fplugin=name handled differently as -fplugin=`gcc > -print-file-name=plugin`/cc1/name.so for cc1 and as -fplugin=`gcc > -print-file-name=plugin`/lto1/name.so for lto1 in > http://gcc.gnu.org/ml/gcc/2011-05/msg00331.html were both a small step > solution to that requirement. You said no to both!!
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). 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. >> >> 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. 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. 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]. > As you see, I (& Pierre) have difficulties to even suggest small > improvements (since Richard Guenther always say no) so I don't You are really an idiot and I should stop communicating with you, Basile Starynkevitch. Thank you very much (and yes, I stopped reading here). For the record, Diego, don't consider me saying nothing to Basiles mails in future that I agree on what he wants to do. Richard.
