On Thu, Jul 31, 2014 at 01:12:54PM -0600, Tom Tromey wrote: > Richard> Can you briefly elaborate on how this relates to the JIT work from > Richard> David Malcom? > > I think Trevor answered this bit well but I had a bit more to add... > > Richard> Just throwing in my mental notes from the Summit here. I really > Richard> wonder how libcc1 falls in into this picture and if it would stand > Richard> in the way of re-organizing main program flow and/or making > Richard> frontends shared objects. > > FWIW the plugin is really quite small. It uses just a few things from > the C front end. Earlier patches in the series also add a couple of ad > hoc hooks to the C front end so that the plugin can insert itself. > However it really isn't much -- primarily I think due to the simplicity > of C; I expect hooking into g++ will be trickier. > > I don't think this plugin will be much of a barrier to anything in gcc. > It hooks in to gcc in the same way as any other plugin (aside from those > ad hoc hooks). You can look through plugin.cc in the patch to see what > parts of gcc's internals uses.
the plugin part seems fine, but I do find my self wondering if there's a better way of doing the hooks into C, if they can be more genrally useful. I'm not complaining about them at all it just seems like its worth thinking about what they tell us we should make better in the future. > One way of looking at it is -- if gcc changes break this plugin, they'll > probably break every plugin. So it's a good thing :) > > Richard> [ideally both frontends and targets would be shared objects, but of > Richard> course even frontends have target dependencies pulled in via > Richard> target macros at the moment...] > > We actually started development with this approach. Our first working > version of this project was based on David Malcolm's JIT branch. We > turned cc1 into a .so and had gdb dlopen it. Then we did the > compilation parts in-process. > > We ended up going with the plugin approach because it has better fault > tolerance. With the cc1.so approach, if we could provoke a crash -- not > uncommon given that we were calling gcc internals in a new and exciting > way -- then the whole debug session came down. out of process seems very reasonable, but I do hope we'll fix the crashes since there's any number of other uses for cc1 as a library. Trev > Using a plugin avoids this. If gcc crashes, gdb can report an error and > continue on. This is much friendlier for users, making it worth the > extra effort of dealing with multiple processes, RPC, etc. Also, our > fears about the performance of this approach were unfounded, I imagine > because we're generally dealing with very small inputs. > > Tom
