-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Update clang to clang-17 #8108
Update clang to clang-17 #8108
Conversation
/gcbrun trial_build.py skcms--sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
@DavidKorczynski does Fuzz Introspector plugin work with clang15? |
Weird i got this working locally |
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
Yes, when I upgraded the plugin to new pass manager I also added support for llvm 15. See this commit for reference as well: ossf/fuzz-introspector@84d5d7c I will do some testing to verify if its robust If I remember correctly some things changed slightly around the way of enabling the old pass manager. I can't remember -- we should double check this as there seems to be a bit of friction in the pass manager in recent LLVM upgrades |
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
3 similar comments
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
13bfa73
to
fcf6050
Compare
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
1 similar comment
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
fcf6050
to
5416142
Compare
has some i386 build problems |
/gcbrun trial_build.py skcms --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
/gcbrun trial_build.py all --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
The main things failing are python projects because asan_with_fuzzer.so no longer exists. |
Filed: google/atheris#36 |
I have a fix for the python issue: google/atheris#37 |
There's also some rust issues that look like this:
|
There's also some rust issues that look like this:
I think it's because clang's new install location for libc++ is in /usr/local/lib/x86_64-unknown-linux-gnu/ instead of /usr/local/lib/ |
Things work if I copy everything in /usr/local/lib/x86_64-unknown-linux-gnu/ to /usr/local/lib/ but I'm trying to figure out why things broke |
/gcbrun trial_build.py all --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
2 similar comments
/gcbrun trial_build.py all --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
/gcbrun trial_build.py all --sanitizer address coverage memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
@vanhauser-thc I'm getting some afl++ related errors, do you know what the problem is?
I get it on at least these projects: upb tcmalloc cel-cpp abseil-cpp To repro:
They seem to all use bazel (ugh) |
hmm yes there are recent changes in llvm 15 that breaks stuff. when I look at the errors these are actually errors in llvm's own header files:
there is not much we can do when llvm is in a broken state :( lllvm 15 so far has been a shitshow, even more so than 14. we cant even use LTO anymore because the broke lld plugin loading :-( using an older llvm 15 commit works. |
/gcbrun trial_build.py all --sanitizer address memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
1 similar comment
/gcbrun trial_build.py all --sanitizer address memory undefined --fuzzing-engine libfuzzer afl honggfuzz |
If llvm 17 removed a feature that is in llvm 16, the version could be bumped to |
@jonathanmetzman |
Looks like 2b2008a was merged, so could re-try here? |
Bumping to clang-17 would also allow everyone to use the new libc++ hardening feature: https://libcxx.llvm.org/Hardening.html |
Maybe I'll get a chance to do this before/shortly after the new year. I think I'll take a different approach this time where I'll migrate the projects that work right away and fix the broken ones bit by bit. |
Is there a way to start using clang-17 for a single project before it is updated globally for OSS-Fuzz? |
@jonathanmetzman is this PR still on your plate for early next year? If not, it would be nice if there was a definitive direction/guide for keeping the clang version used by specific projects up to date with LLVM release tags (re: #9989). |
@vanhauser-thc Any idea if AFL++ works with llvmorg-18-init-14420-gea3a3b25? |
how can I easily download/test this? |
If you don't need the exact version, you could try the clang nightly from https://apt.llvm.org/ |
the afl++ plugins will need quite some work so they work with llvm 18 ... |
here you go: #11404 |
If you can get us clang-18 support that would be great. I think introspector is the main blocker. |
Okay, I'll look at this today and go for supporting llvmorg-18-init-14420-gea3a3b25 |
Can confirm latest introspector is now ready for llvmorg-18-init-14420-gea3a3b25 and also https://chromium.googlesource.com/chromium/src/tools/clang/+/9eb79319239629c1b23cf7a59e5ebb2bab319a34 When doing the bump, please also remove these lines: oss-fuzz/infra/base-images/base-builder/compile Lines 22 to 25 in ae3cf71
|
@@ -120,7 +121,7 @@ fi | |||
git -C $LLVM_SRC checkout $LLVM_REVISION | |||
echo "Using LLVM revision: $LLVM_REVISION" | |||
|
|||
# For fuzz introspector. | |||
For fuzz introspector. |
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.
Unless this is intentionally meant to cause an error, i would guess this should still be a comment.
@jonathanmetzman fyi, I'd like to bump this one #11667 in an hour or two assuming the trial run is okay -- I don't think it should break anything here, but what is the ETA for this PR begin ready? |
You can bump first. I'm going to try to land this before the end of the week or early next week. |
Need to solve this error:
|
Fixes: #8059