From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31449 invoked by alias); 16 Nov 2007 16:56:03 -0000 Received: (qmail 31431 invoked by uid 22791); 16 Nov 2007 16:56:03 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-105-friday.noc.nerim.net (HELO mallaury.nerim.net) (62.4.17.105) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 Nov 2007 16:56:00 +0000 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by mallaury.nerim.net (Postfix) with ESMTP id 458F44F3CA for ; Fri, 16 Nov 2007 17:55:48 +0100 (CET) Received: from [192.168.0.1] (glinka.lesours [192.168.0.1]) by hector.lesours (Postfix) with ESMTP id 6910D20F1E5 for ; Fri, 16 Nov 2007 17:54:57 +0100 (CET) Message-ID: <473DCB98.3040203@starynkevitch.net> Date: Fri, 16 Nov 2007 17:15:00 -0000 From: Basile STARYNKEVITCH User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 CC: gcc@gcc.gnu.org Subject: Re: Progress on GCC plugins ? References: <47317545.2070708@labri.fr> <20071107164101.GB4550@synopsys.com> <473C9F4E.5090402@google.com> <10711152024.AA00627@vlsi1.ultra.nyu.edu> <18236.49757.881704.165655@zebedee.pink> <18237.25889.543937.924615@zebedee.pink> <18237.49248.609704.541703@zebedee.pink> <18237.51292.763097.467863@zebedee.pink> In-Reply-To: <18237.51292.763097.467863@zebedee.pink> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00446.txt.bz2 Andrew Haley wrote: > > Well, that's where we differ. I don't at all understand how adding > plugins won't make it very much easier. It seems obvious to me that > if there is a reasonably well-defined plugin architecture it will be > vastly easier to export data from gcc's front-ends to a proprietary > compiler. It is entirely beyond my understanding why this isn't also > obvious to you. I beg to disagree. Exporting GCC data outside makes practical sense if the data is somehow stable (e.g. from one version of GCC to the next). But a plugin mechanism does not require any stability of any sort. And the current internal representations are not (in my view) stable (and this is good, I am not criticizing GCC here) in the same sense that the accepted languages & GCC options are stable. For example, the "simple" plugin mechanism many people have implicitly in mind is just: something give you the ability to call a dlsymed function inside a dlopened plugin as a pass in a defined (& fixed) position in passes.c. I tend to believe it is not that difficult to implement (it seems to me that the issue is to get it accepted in the trunk). However, this does not guaranty at all that all the internal representation (e.g. the tree.h and other header files) is stable. In other words, such a plugin yourplugin.so (which you coded for future gcc-4.4.3) might be usable from gcc 4.4.3 but not from gcc 4.4.5, and probably not from gcc-4.5 and certainly not from gcc-5.x I'm probably naive, but I think that there are enough incentives (both technical compatibility as above, also legal requirements per GPL, and community & ethical standards of free software at large) that the author of the plugin has interest to publish his source under GPL together with the yourplugin.so file. So a well defined plugin architecture does not mean any stability of internal representations (in their binary detail) or of the many GIMPLE transformations.... Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***