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

Yaron Keren yaron.keren at gmail.com
Mon Jan 27 21:17:46 PST 2014


With Visual C++, this structure prevents the debugger from working, since
the breakpoints are placed on the main process and not the spawned process.
The cumbersome workaround is to print and capture the child -cc1 command
line and use it instead.

I'm not sure how much crash recovery is useful here, clang never crashes

Seriously, If clang faults doing something the whole compilation job is
very likely to fail anyhow even if clang can recover and compile the other
source files in the job.


2014-01-28 Yuri <yuri at rawbw.com>

> On 01/27/2014 17:38, Richard Smith wrote:
>> 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 this also is not necessary to do. clang can just go through them
> sequentially in the same process. Now it forks itself for each of them one
> by one sequentially.
> Yuri
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/90e38644/attachment.html>

More information about the cfe-dev mailing list