[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