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
