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

[Alp Toker]

On 29/01/2014 00:55, Ted Kremenek wrote:
> On Jan 28, 2014, at 4:35 PM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>> On 28/01/2014 22:20, Ted Kremenek wrote:
>>> On Jan 28, 2014, at 2:16 PM, Yuri <yuri at rawbw.com 
>>> <mailto:yuri at rawbw.com>> wrote:
>>>
>>>> On 01/28/2014 14:10, Ted Kremenek wrote:
>>>>> The few million users of Clang that I deal with never invoke the 
>>>>> compiler directly from the command line.  Most of them probably 
>>>>> don’t know how to.  The use the compiler from an IDE. That can, 
>>>>> however, look at a build log and see that a crash report was 
>>>>> generated for them, including a shell script that can be provided 
>>>>> in a bug report that reruns the compiler with the correct 
>>>>> arguments to reproduce the crash.
>>>> If they don't know how to run a compiler, how can they possibly 
>>>> know know to program anything? Programming is much more complicated 
>>>> and involved than simply running a compiler. And you are saying 
>>>> there are millions of them?
>>>>
>>>> Yuri
>>> For them they know enough to run the compiler.  They can simply 
>>> click “Build” in an IDE.  Sure they need to understand the 
>>> compilation model, as implied by the programming language, but they 
>>> don’t need to memorize all the list of flags, etc., that are needed 
>>> to run the compiler from the command line. I’m not saying that 
>>> everyone doesn’t know how to use the compiler directly from the 
>>> command line, but I’d argue that a very large constituency of 
>>> developers (who clearly have demonstrated that they can write 
>>> software) don’t have this knowledge, nor do they need it.
>>
>> Yuri, Ted,
>>
>> This is an open-ended argument and I think in this case you're *both* 
>> right. It is a handy default to enable a reproducible shell script 
>> and we certainly want to preserve those.
>>
>> The community is however interested in finding lighter ways to 
>> achieve that with a single process, whether it's Breakpad or 
>> something built upon the existing crash handler facilities in LLVM.
>>
>> The ability to disable and debug directly would be useful in some 
>> cases and "copy and paste the -cc1 invocation" isn't ideal so on that 
>> part I agree with Yuri.
>>
>> Alp.
>
> I’m not married to forking clang.  I just don’t think we should 
> regress on this functionality, even temporarily.  It is extremely 
> important to us, far more than being able to debug clang directly 
> without pasting the -cc1 invocation.  For the latter, in my experience 
> one quickly learns what to do if you are hacking on clang.  I won’t 
> argue that it is great, but it’s trivial to do when you compare it 
> against losing good signal from bug reports.
>
> If another solution is available other than forking that accomplishes 
> the same aim with capturing reproducible failure cases, then I think 
> we should adopt that first before dropping forking.  Alternatively, if 
> we preserve the forking behavior, possibly as being conditionally 
> compiled, that’s fine with me.  Within Apple we’ll just continue to 
> build it that way.

Agree fully Ted. Forking is tried and tested and yields bug reports from 
a mass user base that might not otherwise bother. I also like the fact 
that it highlights the separation of concerns between driver and frontend.

The way I see it, if someone proposes a light patch to do in-process 
execution using existing LLVM crash handlers selected at runtime by, 
say, an environment variable that'd be a welcome feature. If however it 
takes conditional compilation I'd be less convinced because that also 
has maintenance cost.

Yuri, interested in taking that up?

Alp.

-- 
http://www.nuanti.com
the browser experts