[PATCH] D52193: RFC: [clang] Multithreaded compilation support

Alexandre Ganea via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 10 12:07:58 PDT 2018


aganea added a comment.

In https://reviews.llvm.org/D52193#1260862, @zturner wrote:

> I can try to get some timings from my machine.  How do we handle crash
>  recovery in the case where we don't spawn a child process?  I thought the
>  whole reason for spawning the cc1 driver as a separate process was so that
>  we could collect and report crash information in a nice way.  Not having
>  that seems like a heavy price to pay.


`clang.exe` has already a general exception handler (installed by `InitLLVM::InitLLVM/sys::PrintStackTraceOnErrorSignal`), which prints the callstack in case of a crash. So you wouldn't need the child process to do post-crash processing.

However, when running within a parent `clang.exe`, the parents calls `Driver::generateCompilationDiagnostics()` after a crash to create the repro (preprocessed source).

In a scenario where a single `clang.exe` is running (no child) we could modify `Driver::generateCompilationDiagnostics()` so it gets called from within the exception handler, and invoke a child process to collect the preprocessed source.

I wrote a fully fledged crash reporting system which does that, so I know that's possible. The tricky thing is to ensure `Driver::generateCompilationDiagnostics()` doesn't touch potentially invalid structures (if a crash occured) or allocate memory. The way around that is to pre-allocate and pre-copy the structures that you will be accessing in the case of a crash. But I don't see it as a hurdle in this case.


Repository:
  rC Clang

https://reviews.llvm.org/D52193





More information about the cfe-commits mailing list