Skip to content

[CMake] Options to control generation of reproducers #143037

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

petrhosek
Copy link
Member

Clang automatically generates a reproducer on crash, but we don't provide any control over the reproducers (whether to generate them only for compiler crashes or linker crashes as well) or their location. This change also additional provides an option to enable generating reproducers in case of an error (and not just crash) which can be helpful in environments such as automated builders to help with reproducing issues.

Clang automatically generates a reproducer on crash, but we don't
provide any control over the reproducers (whether to generate them only
for compiler crashes or linker crashes as well) or their location.
This change also additional provides an option to enable generating
reproducers in case of an error (and not just crash) which can be
helpful in environments such as automated builders to help with
reproducing issues.
@llvmbot llvmbot added the cmake Build system in general and CMake in particular label Jun 5, 2025
@petrhosek
Copy link
Member Author

We've had the equivalent in Fuchsia's build and we enable this option on all our builders (including the error reproducers). This has been invaluable and I'd like have the same for our downstream toolchain builders, but I can imagine these might be also helpful for the upstream LLVM builders, especially if we could make the reproducers available as workflow artifacts.

CMAKE_C_FLAGS CMAKE_CXX_FLAGS CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
endif()

if(LLVM_ERROR_REPRODUCERS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this a string-valued cmake option so that setting =always (or other new modes that might come along) doesn't require fresh cmake plumbing?

@jroelofs
Copy link
Contributor

jroelofs commented Jun 5, 2025

we don't provide any control over the reproducers (whether to generate them only for compiler crashes or linker crashes as well) or their location

Not to dissuade you from this patch (which I think is great!), but FWIW, you can set the CLANG_CRASH_DIAGNOSTICS_DIR environment variable, and clang will dump crash reproducers in that path. This is great for CI, especially in non-llvm projects.

@petrhosek
Copy link
Member Author

we don't provide any control over the reproducers (whether to generate them only for compiler crashes or linker crashes as well) or their location

Not to dissuade you from this patch (which I think is great!), but FWIW, you can set the CLANG_CRASH_DIAGNOSTICS_DIR environment variable, and clang will dump crash reproducers in that path. This is great for CI, especially in non-llvm projects.

That's what we use for our Clang builders at the moment but we're currently investigating a regression in LLD that only manifests on our Mac builders and results in a crash and we need a way to set -fcrash-diagnostics=all (in the runtimes subbuild) which motivated this change (and I hope would be generally useful).

The alternative would be to introduce additional environment variables such as CLANG_CRASH_DIAGNOSTICS and CLANG_GEN_REPRODUCER that correspond to the existing options.

endif()

if(LLVM_CRASH_DIAGNOSTICS_DIR)
check_c_compiler_flag("-fcrash-diagnostics-dir=foo" SUPPORTS_FCRASH_DIAGNOSTICS_DIR)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there value in adding a warning here if this is requested but the host compiler does not support the flag?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmake Build system in general and CMake in particular
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants