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

Alp Toker alp at nuanti.com
Tue Jan 28 17:28:23 PST 2014

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?


the browser experts

More information about the cfe-dev mailing list