This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 5/5] add libcc1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]