On Mon, 2016-02-15 at 10:27 +0100, Richard Biener wrote: > On Sun, Feb 14, 2016 at 3:50 PM, Basile Starynkevitch > <bas...@starynkevitch.net> wrote: > > Dear all > > > > In https://gcc.gnu.org/ml/gcc/2016-02/msg00157.html > > > > Richard Biener (richard dot guenther at gmail dot com) is > > mentioning: > > > > > Help with picking up the partially completed work on a stable > > > plugin > > > (introspection) API is of course welcome. > > > > > > > > Can anyone explain me what and where is that stable plugin > > introspection > > API? > > It's a proposal, follow the thread here (also up-thread). There were > similar > threads with another (python?) plugin API from David Malcom(?) IIRC. > > https://gcc.gnu.org/ml/gcc/2012-09/msg00098.html > > > In https://gcc.gnu.org/ml/gcc/2016-02/msg00159.html I (Basile) > > wrote: > > > > > What exact functions (their name, the source files defining them) > > > in the > > > current GCC trunk > > > are you referring to by your "introspection" word? Last time I > > > checked (a > > > few months ago) > > > there where nothing related to that. Today, the only occurrences > > > of > > > introspection > > > (in GCC trunk svn rev233268) are in Java part and in the > > > libsanitizer. > > > > FWIW, Richard Beiner did not had time or wish to answer to that > > (I've got no answer neither privately nor on the list). > > > > So I am rephrasing my question: > > > > which functions and source files are relevant today in the trunk > > for a > > "stable plugin introspection API"? > > None, it doesn't exist in trunk (nor does Melt exist in trunk). > > > > > > > I did try to find something related, but my search is completely > > unsuccessful yet. > > > > My feeling (and I really hope to be wrong, because any reflective > > or > > introspective > > ability in GCC would help my work in the MELT plugin, see > > http://gcc-melt.org/ for more, a big lot) > > is that today there is no plugin-related introspection API at all > > in GCC. It > > still > > looks today (february 20165) as a wish or some vaporware. > > Correct. It has to be filled with reality from plugin people. I > personally > care zero for plugins but will of course guard what gets into the GCC > repository > itself (a thin translation layer from GCC internals to a "plugin > API", > avoiding the > need to export all of GCCs internals as "API"). > > > I still hope to be very wrong, but then please enlighten me by > > naming the > > actual functions and source files > > related to the plugin introspection API. Or give me some source > > files and > > line numbers > > (in the GCC trunk, i.e. future GCC 6, of february 2016) if you > > like so. > > > > > > Since I am not a native English speaker, I am referring to: > > > > https://en.wikipedia.org/wiki/Type_introspection > > https://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 > > https://en.wikipedia.org/wiki/Homoiconicity > > https://en.wikipedia.org/wiki/Metadata > > https://en.wikipedia.org/wiki/Metaclass > > > > (BTW, MELT does have some of these, but they are currently for MELT > > specific > > features, > > not yet for general GCC ones; this means that I -Basile- value & > > cherish > > these features > > a lot and I am hungry > > to have them inside GCC) > > I proposed to define a stable introspection API because a) people > like the > idea of a stable plugin API (or even ABI!), b) introspection is easy > - no > code modification, only inspection, but also enough for a variety of > academic uses, c) introspection can be reasonably defined compiler > -independent > and thus plugin sharing between, say, GCC and LLVM should be possible > > Step 2 would be to add basic instrumentation support to the API > (add global data, insert calls or simple statements at program > points). > > I wouldn't ever go as far as allowing arbitrary IL modification in a > stable > API as that's not going to work and I believe in "real passes" living > in GCC itself. > > To sum up: if you like your issues resolved help driving that tiny > abstraction > layer.
FWIW I have another attempt at a plugin API here: https://github.com/davidmalcolm/libir This is at the "rough prototype" stage. It provides an abstraction layer that hides the GCC headers. In particular, it provides isolation from the underlying GCC version; IIRC I had in working with gcc 4.7, 4.8, 4.9 and 5 (which is why I see it living as a separate project outside of any specific gcc tree). Example plugins using it can be seen here: written in C++: https://github.com/davidmalcolm/libir/blob/master/test-plugin.cc written in C: https://github.com/davidmalcolm/libir/blob/master/test-plugin.c The C API is rather verbose, but I was aiming at something that's easy to wrap (e.g. for writing C++ or Python bindings), rather than something you'd code to by hand in C. (I'm aiming for the "Hourglass" design pattern, fwiw): http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfa ces-for-c-apis (That said, I already have a large list of other tasks I want to tackle for gcc 7...) > Richard. > > > So it looks like Richard see a "partially completed work" on > > "plugin > > introspection API" > > while I (Basile) don't see even the smallest start about it (or > > even > > consensus about wishing that). > > I hope to be wrong, so please point me some actual piece of code > > related to > > that in GCC 6. > > > > FWIW, it is possible for some C++ program to have some metadata. Qt > > is a > > concrete example. > > http://doc.qt.io/qt-5/metaobjects.html; > > GTK is explicitly mentioning Introspection in > > https://wiki.gnome.org/Projects/GObjectIntrospection > > but I don't see anything remotely related to such things inside > > GCC. > > > > AFAIU, we don't have any programmatic way to query the GCC API > > useful in > > plugins today. > > > > So please help me finding some related features in current GCC 6 > > (trunk) > > code base (in February 2016). > > > > I'm sure that most plugin writers would be pleased to know about > > that. > > > > 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} *** > >
