Re: [PATCH 5/5] add libcc1

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Jul 31, 2014 at 12:44 PM, Trevor Saunders <tsaunders@mozilla.com> wrote:
> On Thu, Jul 31, 2014 at 10:01:15AM +0200, Richard Biener wrote:
>> On Thu, Jul 31, 2014 at 6:47 AM, Jeff Law <law@redhat.com> wrote:
>> > On 06/19/14 14:52, Tom Tromey wrote:
>> >>
>> >> Tom> I've edited this one down by removing the auto-generated stuff , and
>> >> Tom> then compressed it.
>> >>
>> >> Here's a new version of patch #5.
>> >> I've removed the generated code; let's see if it gets through without
>> >> compression.
>> >>
>> >> I think this addresses all the reviews:
>> >>
>> >> * It uses gcc-plugin.m4 to disable the plugin
>> >> * It does some configure checks for needed functionality, and disables
>> >>    the plugin if they are not found
>> >> * libcc1 and the plugin now do a protocol version handshake at
>> >>    startup
>> >> * The diagnostic overriding code is now in the plugin, not in gcc proper
>> >> * gdb now tells libcc1 about the target triplet, and libcc1 uses
>> >>    this to invoke the proper GCC.  This is done by (ewww) searching $PATH.
>> >>
>> >> Tom
>> >>
>> >> 2014-06-19  Phil Muldoon  <pmuldoon@redhat.com>
>> >>             Tom Tromey  <tromey@redhat.com>
>> >>
>> >>         * Makefile.def: Add libcc1 to host_modules.
>> >>         * configure.ac (host_tools): Add libcc1.
>> >>         * Makefile.in, configure: Rebuild.
>> >>
>> >> 2014-06-19  Phil Muldoon  <pmuldoon@redhat.com>
>> >>             Jan Kratochvil  <jan.kratochvil@redhat.com>
>> >>             Tom Tromey  <tromey@redhat.com>
>> >>
>> >>         * aclocal.m4: New file.
>> >>         * callbacks.cc: New file.
>> >>         * callbacks.hh: New file.
>> >>         * cc1plugin-config.h.in: New file.
>> >>         * configure: New file.
>> >>         * configure.ac: New file.
>> >>         * connection.cc: New file.
>> >>         * connection.hh: New file.
>> >>         * findcomp.cc: New file.
>> >>         * findcomp.hh: New file.
>> >>         * libcc1.cc: New file.
>> >>         * libcc1plugin.sym: New file.
>> >>         * libcc1.sym: New file.
>> >>         * Makefile.am: New file.
>> >>         * Makefile.in: New file.
>> >>         * marshall.cc: New file.
>> >>         * marshall.hh: New file.
>> >>         * names.cc: New file.
>> >>         * names.hh: New file.
>> >>         * plugin.cc: New file.
>> >>         * rpc.hh: New file.
>> >>         * status.hh: New file.
>> >
>> > So my biggest concern here is long term maintenance -- who's going to own
>> > care and feeding of these bits over time.
>> >
>> > My inclination is to go ahead and approve, but explicitly note that if the
>> > bits do start to rot that we'll be fairly aggressive at disabling/removing
>> > them.
>> >
>> > Now that my position is out there for everyone to see, give the other
>> > maintainers a few days (say until Monday) to chime in with any objections.
>> >
>> > Obviously if there are no objections and you check in the change, please be
>> > on the lookout for any fallout.  I'm particularly concerned about AIX,
>> > Solaris and other non-linux platforms.
>> >
>> > Does this deserve a mention in the news file?
>>
>> Can you briefly elaborate on how this relates to the JIT work from
>> David Malcom?
>
> I don't think the JIT work helps much here because this library wants to
> feed gcc source not IL, so it needs a front end not just the back.

Ah, ok ...

>> Also during the GCC Summit we talked about JIT and plugins and
>> I mentioned that the JIT API is actually a kind of "stable plugin API"
>> for IL creation.
>
> good point.
>
>> We've also elaborated on why the JIT cannot be a "plugin" at the
>> moment - which is at least partly because we cannot have
>> "frontend plugins".  This is because compilation is currently
>> driven by the frontend which "owns" main() even though it immediately
>> calls into the middle-end and only gets control back via langhooks.
>> So a quite obvious cleanup of the program flow of GCC would be
>> to drive things from a middle-end main() - which would allow
>> a plugin to take over the frontend parts (and which would allow
>> making all frontends shared objects, aka "plugins" to a common
>> middle-end "driver").
>
> sounds nice

Actually after looking again I was wrong.  main.c and toplev.c
are the "driver".  So if we can make all frontends shared objects
with their only interface being their lang_hooks that would be nice
(of course the middle-end still needs to make gazillions of symbols
available to that "plugin").

Of course it won't really help libcc1 as libcc1 isn't a frontend
itself.

>> Just throwing in my mental notes from the Summit here.  I really
>> wonder how libcc1 falls in into this picture and if it would stand
>> in the way of re-organizing main program flow and/or making
>> frontends shared objects.
>
> so the interesting bit of libcc1 is just a plugin, which means it won't
> add any extra work past making plugins work.  On the other hand if you
> could load a library that included the driver and front ends then you'd
> basically have a much simpler libcc1, so I think that work would make
> libcc1 a bit nicer.
>
> Trev
>
>>
>> [ideally both frontends and targets would be shared objects, but of
>> course even frontends have target dependencies pulled in via
>> target macros at the moment...]
>>
>> Richard.
>>
>> > Jeff
>> >