On Thu, Jul 31, 2014 at 12:44 PM, Trevor Saunders <tsaund...@mozilla.com> wrote: > On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote: >> On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law <l...@redhat.com> wrote: >> > On 06/19/14 14:52, Tom Tromey wrote: >> >> >> >> Tom> I've edited this one down by removing the auto-generated stuff , and >> >> Tom> then compressed it. >> >> >> >> Here's a new version of patch #5. >> >> I've removed the generated code; let's see if it gets through without >> >> compression. >> >> >> >> I think this addresses all the reviews: >> >> >> >> * It uses gcc-plugin.m4 to disable the plugin >> >> * It does some configure checks for needed functionality, and disables >> >> the plugin if they are not found >> >> * libcc1 and the plugin now do a protocol version handshake at >> >> startup >> >> * The diagnostic overriding code is now in the plugin, not in gcc proper >> >> * gdb now tells libcc1 about the target triplet, and libcc1 uses >> >> this to invoke the proper GCC. This is done by (ewww) searching $PATH. >> >> >> >> Tom >> >> >> >> 2014-06-19 Phil Muldoon <pmuld...@redhat.com> >> >> Tom Tromey <tro...@redhat.com> >> >> >> >> * Makefile.def: Add libcc1 to host_modules. >> >> * configure.ac (host_tools): Add libcc1. >> >> * Makefile.in, configure: Rebuild. >> >> >> >> 2014-06-19 Phil Muldoon <pmuld...@redhat.com> >> >> Jan Kratochvil <jan.kratoch...@redhat.com> >> >> Tom Tromey <tro...@redhat.com> >> >> >> >> * aclocal.m4: New file. >> >> * callbacks.cc: New file. >> >> * callbacks.hh: New file. >> >> * cc1plugin-config.h.in: New file. >> >> * configure: New file. >> >> * configure.ac: New file. >> >> * connection.cc: New file. >> >> * connection.hh: New file. >> >> * findcomp.cc: New file. >> >> * findcomp.hh: New file. >> >> * libcc1.cc: New file. >> >> * libcc1plugin.sym: New file. >> >> * libcc1.sym: New file. >> >> * Makefile.am: New file. >> >> * Makefile.in: New file. >> >> * marshall.cc: New file. >> >> * marshall.hh: New file. >> >> * names.cc: New file. >> >> * names.hh: New file. >> >> * plugin.cc: New file. >> >> * rpc.hh: New file. >> >> * status.hh: New file. >> > >> > So my biggest concern here is long term maintenance -- who's going to own >> > care and feeding of these bits over time. >> > >> > My inclination is to go ahead and approve, but explicitly note that if the >> > bits do start to rot that we'll be fairly aggressive at disabling/removing >> > them. >> > >> > Now that my position is out there for everyone to see, give the other >> > maintainers a few days (say until Monday) to chime in with any objections. >> > >> > Obviously if there are no objections and you check in the change, please be >> > on the lookout for any fallout. I'm particularly concerned about AIX, >> > Solaris and other non-linux platforms. >> > >> > Does this deserve a mention in the news file? >> >> Can you briefly elaborate on how this relates to the JIT work from >> David Malcom? > > I don't think the JIT work helps much here because this library wants to > feed gcc source not IL, so it needs a front end not just the back.
Ah, ok ... >> Also during the GCC Summit we talked about JIT and plugins and >> I mentioned that the JIT API is actually a kind of "stable plugin API" >> for IL creation. > > good point. > >> We've also elaborated on why the JIT cannot be a "plugin" at the >> moment - which is at least partly because we cannot have >> "frontend plugins". This is because compilation is currently >> driven by the frontend which "owns" main() even though it immediately >> calls into the middle-end and only gets control back via langhooks. >> So a quite obvious cleanup of the program flow of GCC would be >> to drive things from a middle-end main() - which would allow >> a plugin to take over the frontend parts (and which would allow >> making all frontends shared objects, aka "plugins" to a common >> middle-end "driver"). > > sounds nice Actually after looking again I was wrong. main.c and toplev.c are the "driver". So if we can make all frontends shared objects with their only interface being their lang_hooks that would be nice (of course the middle-end still needs to make gazillions of symbols available to that "plugin"). Of course it won't really help libcc1 as libcc1 isn't a frontend itself. >> Just throwing in my mental notes from the Summit here. I really >> wonder how libcc1 falls in into this picture and if it would stand >> in the way of re-organizing main program flow and/or making >> frontends shared objects. > > so the interesting bit of libcc1 is just a plugin, which means it won't > add any extra work past making plugins work. On the other hand if you > could load a library that included the driver and front ends then you'd > basically have a much simpler libcc1, so I think that work would make > libcc1 a bit nicer. > > Trev > >> >> [ideally both frontends and targets would be shared objects, but of >> course even frontends have target dependencies pulled in via >> target macros at the moment...] >> >> Richard. >> >> > Jeff >> >
