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

Yaron Keren yaron.keren at gmail.com
Mon Jan 27 21:53:56 PST 2014


Hi,

Helping the developers reproduce bugs is very important, certainly.

What information do we get from a spawned process crash that we can't get
from a "combined" process crash? the command line invocation of the spawned
process?

Yaron




2014-01-28 David Blaikie <dblaikie at gmail.com>

>
>
>
> 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/20140128/0ace55ac/attachment.html>


More information about the cfe-dev mailing list