-
Notifications
You must be signed in to change notification settings - Fork 108
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
Add C specific harness generation logic #337
Comments
This was referenced Jun 15, 2024
Merged
The first step has been achieved with #338 |
DavidKorczynski
added a commit
that referenced
this issue
Jun 18, 2024
This implements the first step of #337 Adds a harness generation flow that, in comparison to the existing default builder: - Provides repository link for the target project. - Is C-specific, uses no CPP code language or similar. - Includes post-processing on the generated code to add certain header files we always want in the harnesses. - Adds constraints on header files the LLM should include in the harnesses. Does this by providing absolute paths to header files in the OSS-Fuzz containers. - Uses some new fuzz introspector APIs to help with context. This PR was made to have no intrusion on the existing workflow, i.e. experiments can continue as they are running now. However, there are several improvements that can be made and I prefer to have these in follow-up PRs: 1) Fixing logic relies on the default prompt builder. This is because the code fixer creates a new prompt builder https://github.com/google/oss-fuzz-gen/blob/09d2235f3957c4d43367ecbd7f3f88147b487abf/llm_toolkit/code_fixer.py#L408 This in fact means that the C++ default logic is used for fixing JVM targets. I would like to change the flow here in the medium term such that the code fixing logic reuses the one we used for main harness generation. I think this should be changed so the prompt builder comes closer to a "harness generator" abstraction and has more knowledge of the target under analysis. But, I prefer to do this later as the PR is already big. 2) Integrate so we can run experiments in the CI with bother or either harness generation flows. 3) Add new features to the prompt builder. Ref: #337 --------- Signed-off-by: David Korczynski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The default C++ logic has some limitations for C projects that's causing failures during e.g. builds. A C-specific flow would benefit in alleviating these and also open the door up on how to add more harness-generation workflows. Majority of this will need changes in
prompt_builder
by simply adding a new prompt class.I'd like to take the following high-level steps to achieve this:
The text was updated successfully, but these errors were encountered: