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

[Manuel Klimek]

On Tue, Jan 28, 2014 at 9:35 PM, Ted Kremenek <kremenek at apple.com> wrote:

> On Jan 28, 2014, at 12:15 PM, Manuel Klimek <klimek at google.com> wrote:
>
> On Tue, Jan 28, 2014 at 9:11 PM, Ted Kremenek <kremenek at apple.com> wrote:
>
>> 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.
>>
>
> Will that still work if the crash comes from a dependent module?
>
>
> I’m not 100% certain it will cover all cases, but I have seen in the case
> of modules that the generated preprocessed file contains @import lines for
> importing modules.
>

I'm more concerned about the path in the code when we decide to actually
compile a module the current module / translation unit depends on (function
compileModule in CompilerInstance.cpp). That seems to basically take the
part of a poor man's "driver", copying the options from the original
translation unit, initializing a new source manager, etc, and then coming
up with a new CompilerInstance...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/997cd354/attachment.html>