[cfe-dev] Why clang needs to fork into itself?

Ted Kremenek kremenek at apple.com
Tue Jan 28 12:11:43 PST 2014

On Jan 28, 2014, at 12:08 PM, Manuel Klimek <klimek at google.com> wrote:

> On Tue, Jan 28, 2014 at 2:38 AM, Richard Smith <metafoo at gmail.com> wrote:
> On Mon Jan 27 2014 at 4:51:40 PM, Yuri <yuri at rawbw.com> wrote:
> On 01/27/2014 16:37, Jean-Daniel Dupas wrote:
> > If you want to debug/profile clang, you can invoke it directly with the -cc1 flag, and passing the right arguments.
> >
> > To get the full command line used to invoke the real compilation process, you can use the -### argument:
> >
> > clang -### -c -emit-llvm c.cpp
> >
> > For the record, in the early days, the clang driver was a separate binary that used to invoke the compiler (which was called ccc IIRC).
> > Some time ago, the driver and the compiler were merged into a single clang binary, but it continue to work the same way it used to do. That explains why it executes itself.
> I see.
> So I wrote up my proposal to make this opt-in:
> http://llvm.org/bugs/show_bug.cgi?id=18638
> I don't think the reasons why we spawn another binary have really been captured in this thread. The biggest reason is that the clang driver accepts multiple files to compile:
>    clang foo.c bar.c baz.c -o thing
> ... and runs one compile process for each source file (and in this case, one link process for the binary). Crash recovery is just a nice side-effect of having a separate driver and frontend. The main benefit is that we get a consistent execution model regardless of the number of files passed to the driver.
> But nowadays with modules we also have in-process compilation steps of dependent modules without going through the whole driver enchilada, so is this becoming an obsolete argument?

Clang forking itself remains quite useful for getting test cases for crashers.  If the forked clang crashes the parent clang process tries to generate a preprocessed source to serve as a test case.  We have found this to be invaluable for users to file useful test cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/dc15acea/attachment.html>

More information about the cfe-dev mailing list