rnk added a comment. In https://reviews.llvm.org/D52193#1260933, @aganea wrote:
> 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. Our existing stack dumper breaks all kinds of rules in this area. It uses std::vectors to make the stack trace. As much as it pains me that it's not 110% correct, nobody has complained so far that they don't get stack traces from clang when it crashes asynchronously inside of malloc. Nice, the numbers for avoiding -cc1 are pretty compelling. It would also make debugging easier. I'd love to never see that question again on cfe-dev. To handle pre-processed source generation, the best idea I could come up with was to pre-allocate the "generate crash diagnostics" command line and then spawn off a child process in the signal/exception handler to the heavy lifting. We're not concerned about generating pre-processed source in cases of system low memory or instability, so the relative unreliability of creating a child process isn't a huge concern. Repository: rC Clang https://reviews.llvm.org/D52193 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
