[cfe-dev] Why clang needs to fork into itself?
dblaikie at gmail.com
Mon Jan 27 21:33:32 PST 2014
On Mon, Jan 27, 2014 at 9:17 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
> 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.
Yep, we're all familiar with this - all of us working on Clang have been
doing this for a while now...
> I'm not sure how much crash recovery is useful here, clang never crashes
The bug reports beg to differ (when you work on the compiler you see just
how much it can fail).
> 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.
Crash reporting/handling isn't likely to allow the user to continue without
changing their code - but it will give them some useful information to
> 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
>>> 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
>> 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.
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev