[llvm-dev] [RFC] Generating LLD reproducers on crashes

[Alexandre Ganea via llvm-dev]

Sounds like a good idea. I suppose in case of a crash, Driver::generateCompilationDiagnostics() could invoke the linker again with --reproduce? That would be the "cheap" version of option 2.

-----Message d'origine-----
De : David Blaikie <dblaikie at gmail.com> 
Envoyé : April 21, 2021 12:47 PM
À : Alexandre Ganea <alexandre.ganea at ubisoft.com>
Cc : Fangrui Song <maskray at google.com>; Petr Hosek <phosek at chromium.org>; Haowei Wu <haowei at google.com>; llvm-dev at lists.llvm.org
Objet : Re: [llvm-dev] [RFC] Generating LLD reproducers on crashes

> 2. There are cases where the CrashRecoveryContext isn't perfect: a stack overflow, a severe heap corruption, corruption of any global state. These happen quite rarely, but would prevent the gen-reproducer from creating anything, however I expect we would still see an invalid return code in the build log. A 100% solution would need forking LLD at startup, along the lines of -fno-integrated-cc1. The new cmd-line flag from 1. could eventually support this multi-process/forking scenario as well.

Clang used to do this (& still can, I guess) with the whole driver+cc1 separation. I wonder if clang's crash reporting in the driver could be generalized/special cased to also work with invocations of lld from the clang driver? I don't think this'd be good for all cases (some builds do run the linker directly without using the compiler driver) but would help with the "severe" crash category, I think?