-
Notifications
You must be signed in to change notification settings - Fork 117
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
Enable -flto and -fsanitize=cfi in clang #2222
Conversation
99bf458
to
fee753b
Compare
@PatKamin is there any particular reason the fuzz testing explicitly sets "-g"? It seems to trigger a weird edge case when used in release mode when -lto is also enabled, which crashes the linker. |
I've added it after libFuzzer examples: https://llvm.org/docs/LibFuzzer.html#fuzzer-usage |
bd54953
to
3782c5f
Compare
25983b0
to
abcb72b
Compare
4132a6e
to
49770db
Compare
Pre-commit MR for: oneapi-src/unified-runtime#2222
Pre-commit MR for: oneapi-src/unified-runtime#2222
@@ -51,7 +51,9 @@ target_link_libraries(fuzztest-base | |||
${PROJECT_NAME}::headers | |||
${PROJECT_NAME}::common | |||
-fsanitize=fuzzer) | |||
target_compile_options(fuzztest-base PRIVATE -g -fsanitize=fuzzer) | |||
# When built with -g and -flto (which is required by some hardening flags), this causes a segfault in (upstream) | |||
# LLVM 14-15 while linking when CMAKE_BUILD_TYPE is Release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we have an issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. It feels like an upstream compiler bug, and we don't need to build with -g
here anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe an upstream issue is appropriate then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, this is fixed in LLVM 16+, so either they knew about it and fixed it or it happened to be fixed anyway with another change.
Pre-commit MR for: oneapi-src/unified-runtime#2222
a210b80
to
4de2500
Compare
96708bb
to
15aaebe
Compare
Pre-commit MR for: oneapi-src/unified-runtime#2222
Note that this flagged up a few issues, for which followup tickets were created: * oneapi-src#2323 * oneapi-src#2309 * oneapi-src#2324
15aaebe
to
58dabfe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
command-buffer match file changes LGTM, I've created an internal ticket for our team to look into the fails further.
@oneapi-src/unified-runtime-level-zero-v2-write This flags up an issue with the event pool tests, so I've disabled it for now if CFI is to be enabled. Could you look and see if this is something you're okay with me doing? |
Pre-commit MR for: oneapi-src/unified-runtime#2222 --------- Co-authored-by: Callum Fare <[email protected]>
Note that this flagged up a few issues, for which followup tickets
were created:
-flto -fsanitize=cfi
causes linker errors on the CI fuzz testing job #2323-flto -fsanitize=cfi
cause issues on the CUDA CI node #2309level_zero_event_pool
tests fail with SIGILL when the CFI sanitizer is enabled #2324