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

[David Blaikie]

On Mon, Jan 27, 2014 at 9:17 PM, Yaron Keren <yaron.keren at gmail.com> wrote:

> Hi,
>
> 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
report bugs.


>
> Yaron
>
>
>
> 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
>>
>
>
> _______________________________________________
> 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/20140127/ba36ddb4/attachment.html>