This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 5/5] add libcc1
- From: Tom Tromey <tromey at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 31 Jul 2014 13:12:54 -0600
- Subject: Re: [PATCH 5/5] add libcc1
- Authentication-results: sourceware.org; auth=none
- References: <1400254001-12038-1-git-send-email-tromey at redhat dot com> <87oayx4l0x dot fsf at fleche dot redhat dot com> <87bntobp1f dot fsf at fleche dot redhat dot com> <53D9CA7B dot 3040709 at redhat dot com> <CAFiYyc0VpAG6s+JbQL-GpO2woSznGWzezD6wHTQoO9ZXH2QCEw at mail dot gmail dot com>
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.