On Thu, Jul 31, 2014 at 01:12:54PM -0600, Tom Tromey wrote: > 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.
Given that what GDB wants is not a JIT, but reuse the C (and later on C++) FEs, I think the plugin approach is just fine for this. Jakub