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. 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. 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
