Nice — below is a ready-to-drop-in libFuzzer harness for processor::process, plus a minimal CMakeLists.txt snippet and an example CMakePresets.json preset you can add to your project. The fuzz target simply feeds libFuzzer's input bytes to processor::process as a std::vector<std::uint8_t>.

1) fuzz_processor.cpp (fuzz target)

cpp
Skopiuj kod
// fuzz_processor.cpp
// Build this with libFuzzer (clang) and sanitizers enabled.

#include <cstdint>
#include <cstddef>
#include <vector>

// include your headers that define `processor` and `some_object`
// adjust the include path as needed for your project:
#include "processor.hpp"

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // Convert libFuzzer input into the form expected by processor::process
    const std::vector<std::uint8_t> input(data, data + size);

    // Create a processor instance and call process()
    // NOTE: we intentionally do NOT catch exceptions here so crashes / UB surface to libFuzzer.
    processor p;
    some_object out = p.process(input);

    // Optionally: do a light sanity touch on `out` to avoid it being optimized away.
    // (Only necessary if some compilers optimize away unused results.)
    (void)out;

    return 0; // required by libFuzzer signature
}

// Optional: if your target needs initialization you can implement this
// extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv) { /* init */ return 0; }

Notes about the harness code

• The function must be extern "C" with the LLVMFuzzerTestOneInput signature so libFuzzer can call it.

• I intentionally do not catch exceptions inside LLVMFuzzerTestOneInput. Letting exceptions or crashes surface helps libFuzzer find real bugs (adjust if your code throws many expected exceptions you want to ignore).

• If your processor constructor is expensive or needs global setup, implement LLVMFuzzerInitialize to perform one-time setup and create a shared instance.

2) CMakeLists.txt snippet

Add a fuzz target to your existing CMake project. Replace your_library_target with the target/library that contains processor (or link the objects directly if appropriate).

cmake
Skopiuj kod
cmake_minimum_required(VERSION 3.18)
project(MyProject CXX)

# your normal project targets...
# add_library(your_library_target ...)

# Fuzz target
add_executable(fuzz_processor fuzz_processor.cpp)

# Link with the library that contains processor (change name to match your target)
target_link_libraries(fuzz_processor PRIVATE your_library_target)

# Compiler and linker flags for libFuzzer + ASAN/UBSAN
# These flags expect clang/clang++ and libFuzzer support (-fsanitize=fuzzer).
target_compile_options(fuzz_processor PRIVATE
    -g
    -O1                 # libFuzzer recommendation for fast instrumentation; change if desired
    -fno-omit-frame-pointer
    -fsanitize=fuzzer,address,undefined
)

target_link_options(fuzz_processor PRIVATE
    -fsanitize=fuzzer,address,undefined
)

# If your project sets CXX_STANDARD, ensure fuzz target matches it:
target_compile_features(fuzz_processor PRIVATE cxx_std_17)

Important

• -fsanitize=fuzzer requires clang (clang++). If you are using GCC, libFuzzer linking is different and typically requires an external libFuzzer library; using clang is simpler.

• Adjust optimization level (-O1/-O2) depending on needs. libFuzzer docs recommend -O1 for faster iteration but -O2 is also used widely.

3) Example CMakePresets.json snippet

If you use CMake presets, here's a sample CMakePresets.json entry that sets clang as the compiler and configures a Debug-ish build with sanitizers. Add this to your project's CMakePresets.json or merge with your existing file.

json
Skopiuj kod
{
  "version": 3,
  "configurePresets": [
    {
      "name": "fuzz-clang",
      "displayName": "Configure for libFuzzer (clang, ASAN, UBSAN)",
      "description": "Use clang/clang++ and build fuzz targets with sanitizers.",
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build-fuzz",
      "cacheVariables": {
        "CMAKE_C_COMPILER": "/usr/bin/clang",
        "CMAKE_CXX_COMPILER": "/usr/bin/clang++",
        "CMAKE_BUILD_TYPE": "RelWithDebInfo"
      }
    }
  ]
}

Adjust CMAKE_C_COMPILER paths to match your environment (for example: /usr/bin/clang++ on Linux, or a path to a custom clang).

4) Build & run (example commands)

Assuming the preset above and ninja generator:

bash
Skopiuj kod
# configure
cmake --preset fuzz-clang

# build fuzz target
cmake --build out/build-fuzz --target fuzz_processor -j

# run the fuzzer (example: run indefinitely; libFuzzer accepts various flags)
./out/build-fuzz/fuzz_processor -jobs=4 -max_total_time=3600

Replace or remove -max_total_time as needed — libFuzzer supports many runtime flags (-runs, -jobs, -seed, -artifact_prefix, ...). See libFuzzer docs for details.

5) Extra suggestions / hardening

• Enable AddressSanitizer, UndefinedBehaviorSanitizer (already included above).

• Consider -fsanitize=leak if you want leak detection, but note it can slow fuzzing and complicate reproduction.

• If processor::process needs external state (files, config), implement LLVMFuzzerInitialize to set it up.

• If processor::process is stateful and you want to avoid reconstructing processor per input, create a static processor in LLVMFuzzerInitialize and reuse it — but be careful about residual state between runs (prefer stateless or reset between runs).

• Use -artifact_prefix=./artifacts/ to collect crashing inputs for later analysis.

If you'd like, I can:

• adapt the harness to catch/ignore std::exception (if you expect a lot of thrown exceptions),

• create a reproducible minimization script (how to reproduce a crash with libFuzzer and clang),

• or prepare a Dockerfile/CI step that runs the fuzzer in your CI environment.

Tell me which of those you want and I’ll produce it right away.

Got you 👍 On Ubuntu, installing clang is straightforward. Here are the clean, practical options depending on what you want.

Option 1: Install the default clang (easy, usually good enough)

This installs the clang version that matches your Ubuntu release.

bash
Skopiuj kod
sudo apt update
sudo apt install -y clang

Verify:

bash
Skopiuj kod
clang --version
clang++ --version

This is usually enough for libFuzzer + sanitizers.

Option 2: Install a specific / newer clang version (recommended for fuzzing)

If you want a modern clang (often better libFuzzer + sanitizer support):

bash
Skopiuj kod
sudo apt update
sudo apt install -y clang-17 lldb-17 lld-17

(Replace 17 with 16, 18, etc., depending on availability for your Ubuntu version.)

Use it explicitly:

bash
Skopiuj kod
clang-17 --version
clang++-17 --version

Or set it as default:

bash
Skopiuj kod
sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-17 100
sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/bin/clang++-17 100

Then:

bash
Skopiuj kod
clang --version

Option 3: LLVM official apt repository (latest clang)

Best if Ubuntu’s repo is too old.

bash
Skopiuj kod
wget https://apt.llvm.org/llvm.sh
chmod +x llvm.sh
sudo ./llvm.sh 17

This installs:

• clang-17

• clang++-17

• lld, lldb, llvm-symbolizer

Recommended extras for fuzzing

These make debugging crashes much nicer:

bash
Skopiuj kod
sudo apt install -y llvm llvm-dev llvm-runtime

And make sure symbolizer is found:

bash
Skopiuj kod
export LLVM_SYMBOLIZER=$(which llvm-symbolizer)

(You can add that to ~/.bashrc.)

Quick sanity check for libFuzzer support

Run:

bash
Skopiuj kod
echo 'int main(){}' | clang++ -fsanitize=fuzzer -x c++ -

If it compiles without errors, libFuzzer is available 👍

TL;DR (what I’d actually do)

On modern Ubuntu:

bash
Skopiuj kod
sudo apt update
sudo apt install -y clang-17 lld-17 lldb-17 llvm-17
export LLVM_SYMBOLIZER=$(which llvm-symbolizer-17)

If you tell me your Ubuntu version (22.04, 24.04, etc.), I’ll give you the exact best clang version and repo combo for it.

Yep — there is a way to use clang portably without touching system libraries 👍
There are a few practical options, with different trade-offs. I’ll start with the one that works best for CMake + libFuzzer setups.

✅ Best option: LLVM “portable” binary tarballs

LLVM provides self-contained prebuilt clang/LLVM binaries you can unpack anywhere (no apt, no system pollution).

Download

From: https://github.com/llvm/llvm-project/releases

Example (Linux x86_64, clang 17):

bash
Skopiuj kod
wget https://github.com/llvm/llvm-project/releases/download/llvmorg-17.0.6/clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04.tar.xz

Extract

bash
Skopiuj kod
tar -xf clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04.tar.xz

You’ll get something like:

bash
Skopiuj kod
clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04/
├── bin/clang
├── bin/clang++
├── bin/llvm-symbolizer
├── lib/
├── include/

Use it (no system changes)

bash
Skopiuj kod
export LLVM_HOME=$PWD/clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04
export PATH=$LLVM_HOME/bin:$PATH
export LLVM_SYMBOLIZER=$LLVM_HOME/bin/llvm-symbolizer

Now:

bash
Skopiuj kod
clang --version
clang++ --version

✔ No apt
✔ No system library changes
✔ Works perfectly with -fsanitize=fuzzer,address,undefined
✔ Ideal for CI and reproducible builds

Using it with CMakePresets.json

Point CMake directly at this clang:

json
Skopiuj kod
{
  "version": 3,
  "configurePresets": [
    {
      "name": "fuzz-portable-clang",
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build-fuzz",
      "cacheVariables": {
        "CMAKE_C_COMPILER": "/path/to/clang+llvm-17.0.6/bin/clang",
        "CMAKE_CXX_COMPILER": "/path/to/clang+llvm-17.0.6/bin/clang++"
      }
    }
  ]
}

This is the cleanest approach if you want zero system interference.

⚠️ Important libc detail (very relevant!)

Clang itself is portable, libc is not.

LLVM tarballs:

• Use system glibc

• Do not bundle libc

That means:

• Works on the same or newer glibc than it was built for

• Might fail on older distros

Rule of thumb:

Build on the oldest distro you need to support

Example:

• Ubuntu 22.04 clang binaries → safe on 22.04, 24.04

• Not guaranteed on 20.04

🧪 Alternative: Fully hermetic via Docker (most isolated)

If you want absolute isolation:

bash
Skopiuj kod
docker run --rm -it \
  -v "$PWD:/work" \
  llvmorg/llvm:17 \
  bash

Pros:

• 100% reproducible

• No host contamination

• Perfect for fuzzing in CI

Cons:

• Heavier

• Less convenient locally

⚙️ Alternative: Build clang yourself (rarely worth it)

You can build LLVM from source with:

• custom install prefix

• bundled libc++ / compiler-rt

But:

• very slow

• complex

• rarely needed unless you need special patches

⭐ What I recommend for your case

For CMake + libFuzzer + Ubuntu, minimal pain:

1. Use LLVM prebuilt tarball

2. Export PATH + LLVM_SYMBOLIZER

3. Point CMake preset to that clang

4. Done

This avoids:

• apt

• update-alternatives

• system lib pollution

• CI weirdness

If you want, I can:

• give you the exact download URL for your Ubuntu version

• show how to make a project-local toolchains/clang/ setup

• write a CMake toolchain file instead of hardcoding compilers

• help you make fuzzing fully reproducible in CI

Just tell me which one you want.

It stands for “Release Candidate 2.”

In LLVM 22.1.0-rc2:

• 22.1.0 → the intended final version number

• rc → release candidate

• 2 → the second release candidate for that version

What a release candidate means in practice

A release candidate is a build that:

• is feature-complete

• is expected to become the final release if no serious bugs are found

• is published so users can test it on real workloads (like your fuzzing setup)

So:

• rc1 → first “almost final” build

• rc2 → fixes on top of rc1

• …

• final release → same code as the last RC, just without the -rcN suffix

Is it safe to use?

• Yes for testing, fuzzing, CI experiments

• Usually yes for development

• Less ideal for long-term production toolchains unless you pin it carefully

For libFuzzer and sanitizer work, RC builds are actually very useful, because:

• they often contain sanitizer fixes not yet in the last stable release

• regressions are rare at this stage

Rule of thumb

• Want maximum stability → use LLVM 21.x.y final

• Want new sanitizer / fuzzer improvements → 22.1.0-rc2 is fine

• Want reproducible builds → pin exactly 22.1.0-rc2, not “latest RC”

If you want, I can also explain:

• how LLVM’s release process works end-to-end

• how long RCs usually live before final

• whether there are known differences between 22.1.0-rc2 and the final 22.1.0

Just say the word 🙂

Good catch — that wasn’t accidental, and it’s a fair question 👍
Short version: 17.0.6 is the “boring-but-solid” choice. Here’s the full reasoning.

1️⃣ LLVM 17 is the current long-term stable workhorse

LLVM releases follow this pattern:

• N → latest stable

• N+1 → active development / early adopters

• N−1 → very stable, widely deployed

At the time people standardized toolchains broadly:

• LLVM 17 became the “everyone uses this” baseline

• It has multiple patch releases (17.0.6), meaning:

  • critical bugs fixed

  • sanitizer regressions ironed out

  • ABI and behavior stabilized

For fuzzing, maturity matters more than novelty.

2️⃣ libFuzzer + sanitizers favor mature releases

libFuzzer, ASan, UBSan, and compiler-rt are tightly coupled to clang.

In practice:

• New LLVM major versions often introduce:

  • new sanitizer checks

  • rewritten instrumentation

  • subtle regressions

• These get fixed in .1, .2, .3… patch releases

17.0.6:

• has been hammered by:

  • Chromium

  • Android

  • OSS-Fuzz

• is known to work well for fuzzing C++ projects

Newer (e.g. 18, 19, 22 RCs):

• may fuzz better

• but are more likely to produce:

  • false positives

  • performance regressions

  • toolchain surprises

3️⃣ Portability: glibc compatibility sweet spot

This one is subtle but important.

LLVM prebuilt binaries are linked against glibc of the build distro.

• LLVM 17 binaries are commonly built on Ubuntu 20.04 / 22.04

• Newer LLVM releases are increasingly built on newer glibc

Result:

• LLVM 17 runs on:

  • Ubuntu 22.04

  • Ubuntu 24.04

  • many enterprise distros

• Newer releases may not run on older systems

So 17 is a safe portability floor.

4️⃣ CMake ecosystem stability

CMake + clang integration lags slightly behind LLVM HEAD.

With LLVM 17:

• -fsanitize=fuzzer works everywhere

• CMake detects compiler features reliably

• Fewer surprises with:

  • try_compile

  • CheckCXXCompilerFlag

  • LTO / ThinLTO flags

With bleeding-edge LLVM:

• you occasionally hit CMake modules that haven’t been tested against it yet

5️⃣ Why not LLVM 18 / 19 / 22-rc?

You can use them. I do — selectively.

But I wouldn’t recommend them as a default example unless:

• you explicitly asked for “latest”

• you’re testing sanitizer changes

• you’re already pinning toolchains per-project

Examples:

• LLVM 18/19 → fine, but still settling

• LLVM 22.1.0-rc2 → excellent for experimentation, not yet boring

Practical recommendation matrix

If you want a “future-proof” setup

A nice compromise is to support two toolchains:

text
Skopiuj kod
toolchains/
├── llvm-17/   # stable, default
└── llvm-22/   # experimental / RC

And switch via CMake presets.

If you tell me:

• your Ubuntu version

• whether this is CI / local dev / fuzz farm

• how long you want builds to remain reproducible

…I’ll tell you exactly which LLVM version I’d pin and why.

You’re observing a real policy shift, not a glitch — and your conclusion is correct 👍
LLVM didn’t “forget” Ubuntu 22.04 packages after 17.0.6; they intentionally stopped producing them.

Here’s what’s going on under the hood.

The short answer

LLVM 17.0.6 is the last release built on Ubuntu 22.04 because LLVM moved its official Linux build baseline to a newer distro.

Once that happened, they stopped publishing tarballs explicitly labeled ubuntu-22.04.

The longer (and more useful) explanation

1️⃣ LLVM binary tarballs are built on specific distros

LLVM doesn’t just say “Linux” — each tarball is built on one concrete distribution, which determines:

• glibc version

• libstdc++ ABI

• kernel/syscall expectations

That’s why filenames include things like:

Skopiuj kod
clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04.tar.xz

This tells you exactly what glibc baseline the binaries require.

2️⃣ After LLVM 17, the build baseline moved forward

Starting after the LLVM 17 release line, LLVM maintainers:

• dropped Ubuntu 22.04 as a primary build host

• moved to a newer baseline (effectively Ubuntu 24.04 / newer glibc)

Why they did this:

• newer compilers need newer system headers

• newer C++ standard library features

• less backporting pain

• fewer CI failures across architectures

This is a common lifecycle step once a distro is no longer “new”.

3️⃣ Why you still see Linux tarballs — just not 22.04-labeled ones

For newer LLVM releases, you’ll see things like:

Skopiuj kod
clang+llvm-18.x.x-x86_64-linux-gnu.tar.xz

or builds tied to newer baselines.

These binaries:

• may run on Ubuntu 22.04

• but are not guaranteed to

• and LLVM doesn’t want to promise compatibility they can’t test

So they stopped advertising a 22.04-specific artifact.

This is a support guarantee decision, not a technical impossibility.

4️⃣ Why LLVM 17 is special

LLVM 17 is:

• the last release line fully tested on Ubuntu 22.04

• the last one where LLVM CI explicitly validated that environment

• effectively the “LTS-by-convention” release for that distro

That’s why you still see:

Skopiuj kod
clang+llvm-17.0.6-…-ubuntu-22.04.tar.xz

And nothing newer.

What this means for you (practically)

✅ If you are on Ubuntu 22.04

Best options:

1. Stick to LLVM 17.0.6

   • fully compatible

   • officially supported

   • boring and reliable (good!)

2. Use newer LLVM anyway — but knowingly

   • try newer generic Linux tarballs

   • accept possible glibc/libstdc++ issues

   • test carefully

3. Use apt.llvm.org

   • they do still build clang 18/19/… for 22.04

   • but that’s no longer “portable tarball”, it’s system-integrated

⚠️ Why this matters a lot for fuzzing

libFuzzer + sanitizers are very sensitive to:

• libc ABI

• libstdc++ mismatch

• unwinder differences

Using a tarball built for a newer glibc on 22.04 can cause:

• sanitizer crashes

• false positives

• symbolization failures

So LLVM’s conservatism here is actually a favor.

Rule of thumb going forward

Bottom line

LLVM 17.0.6 isn’t “old” — it’s the last release that promises Ubuntu 22.04 compatibility.

Everything after that may still work — but LLVM no longer wants to guarantee it.

If you want, I can:

• check whether a specific newer LLVM tarball will run safely on your system

• help you choose between LLVM 17 vs LLVM 22-rc for fuzzing

• show how OSS-Fuzz handles this exact issue in practice

Just tell me what you’re aiming for.

Sure 👍 Here’s the clean, correct way to extract a .tar.xz archive directly into /opt/clang using tar.

1️⃣ Create the target directory

bash
Skopiuj kod
sudo mkdir -p /opt/clang

(Optional but recommended: make it owned by root and readable by everyone.)

2️⃣ Extract the archive into /opt/clang

bash
Skopiuj kod
sudo tar -xJf file.tar.xz -C /opt/clang

Explanation of flags:

• -x → extract

• -J → use xz decompression

• -f → archive file

• -C /opt/clang → change directory before extracting

3️⃣ Check what you got

bash
Skopiuj kod
ls /opt/clang

Typically you’ll see something like:

text
Skopiuj kod
clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04/

4️⃣ (Optional) Flatten the directory

LLVM tarballs usually extract into a versioned subdirectory.
If you want /opt/clang/bin/clang directly:

bash
Skopiuj kod
sudo mv /opt/clang/clang+llvm-*/* /opt/clang/
sudo rmdir /opt/clang/clang+llvm-*

⚠️ Do this only if /opt/clang is empty.

5️⃣ (Optional) Make it usable system-wide (without replacing system clang)

Add to /etc/profile.d/clang.sh:

bash
Skopiuj kod
sudo tee /etc/profile.d/clang.sh >/dev/null <<'EOF'
export PATH=/opt/clang/bin:$PATH
export LLVM_SYMBOLIZER=/opt/clang/bin/llvm-symbolizer
EOF

Or just for your shell:

bash
Skopiuj kod
export PATH=/opt/clang/bin:$PATH
export LLVM_SYMBOLIZER=/opt/clang/bin/llvm-symbolizer

Quick verification

bash
Skopiuj kod
clang --version
which clang

Should point to /opt/clang/bin/clang.

If you want:

• a versioned layout (/opt/clang/17, /opt/clang/22)

• a symlink-based switch (/opt/clang/current)

• a CMake toolchain file pointing at /opt/clang

…say the word and I’ll set it up cleanly.

Sure — here’s the same thing using long option names only, nice and explicit 👍

Create the target directory

bash
Skopiuj kod
sudo mkdir --parents /opt/clang

Extract file.tar.xz into /opt/clang

bash
Skopiuj kod
sudo tar --extract --xz --file=file.tar.xz --directory=/opt/clang

Explanation:

• --extract → extract files

• --xz → use xz decompression

• --file=file.tar.xz → archive file

• --directory=/opt/clang → extract into this directory

Verify extraction

bash
Skopiuj kod
ls /opt/clang

You should see a directory like:

text
Skopiuj kod
clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04/

Optional: flatten the directory (long options)

Only do this if /opt/clang is empty and you want /opt/clang/bin/clang directly:

bash
Skopiuj kod
sudo mv /opt/clang/clang+llvm-*/* /opt/clang/
sudo rmdir --parents /opt/clang/clang+llvm-*

Optional: make it available in PATH

Per-user:

bash
Skopiuj kod
export PATH=/opt/clang/bin:$PATH
export LLVM_SYMBOLIZER=/opt/clang/bin/llvm-symbolizer

System-wide (login shells):

bash
Skopiuj kod
sudo tee /etc/profile.d/clang.sh >/dev/null <<'EOF'
export PATH=/opt/clang/bin:$PATH
export LLVM_SYMBOLIZER=/opt/clang/bin/llvm-symbolizer
EOF

Sanity check

bash
Skopiuj kod
which clang
clang --version

If you want, I can also:

• show how to list archive contents with long options

• extract only a subdirectory from the tarball

• or make a versioned /opt/clang/17 layout with symlinks

Just tell me.

--strip-components=1 tells tar to remove the first directory level from every file path while extracting.

It’s easiest to see with an example.

The problem it solves

Many archives are structured like this:

text
Skopiuj kod
clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04/
├── bin/
│   └── clang
├── lib/
├── include/

If you extract normally:

bash
Skopiuj kod
tar --extract --file=file.tar.xz

you get:

text
Skopiuj kod
./clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04/bin/clang

Sometimes you don’t want that top-level directory.

What --strip-components=1 does

bash
Skopiuj kod
tar --extract \
    --xz \
    --file=file.tar.xz \
    --directory=/opt/clang \
    --strip-components=1

Result:

text
Skopiuj kod
/opt/clang/bin/clang
/opt/clang/lib/...
/opt/clang/include/...

Tar:

• splits each path by /

• removes the first component

• extracts the rest

General rule

Important caveats (this matters)

1️⃣ Paths must have at least N components

If a file path has fewer components than you strip:

• tar skips that file

• no error by default

2️⃣ You can destroy directory structure

If different paths become identical after stripping, files may overwrite each other.

3️⃣ Always inspect first

Before using it, do:

bash
Skopiuj kod
tar --list --file=file.tar.xz

(or --list --xz --file=… for .xz)

Typical real-world use cases

LLVM / GCC / Go / Node tarballs

bash
Skopiuj kod
tar --extract --xz --file=llvm.tar.xz --directory=/opt/clang --strip-components=1

Extract only part of an archive

bash
Skopiuj kod
tar --extract --file=archive.tar \
    --strip-components=2 \
    some/top/dir/file.txt

Mental model

Think of --strip-components=1 as:

“Pretend everything inside the archive started one directory deeper.”

If you want, I can:

• show how to safely combine --strip-components with --wildcards

• explain how it differs from --transform

• help write a defensive extraction command for CI scripts

Just say the word.

This is an important nuance in CMake, so let’s be very precise.

Short, correct answer

👉 You cannot add target_compile_options() or target_link_options() directly in CMakePresets.json.
Those are target-level commands, and presets operate before targets even exist.

But—you can achieve the same effect indirectly in a few clean ways.

Why this doesn’t work conceptually

• CMakePresets.json:

  • sets cache variables

  • selects compilers, generators, build types

• target_compile_options() / target_link_options():

  • operate on targets

  • run inside CMakeLists.txt

  • require the target to already exist

So there is no syntax like this (and never will be):

json
Skopiuj kod
// ❌ impossible
"target_compile_options": ["-fsanitize=address"]

✅ Correct ways to do this

Option 1 (recommended): Use cache variables in presets

(Best for fuzzing / sanitizer builds)

You inject flags globally via cache variables, and your targets inherit them.

Example: CMakePresets.json

json
Skopiuj kod
{
  "version": 3,
  "configurePresets": [
    {
      "name": "fuzz",
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build-fuzz",
      "cacheVariables": {
        "CMAKE_C_COMPILER": "/opt/clang/bin/clang",
        "CMAKE_CXX_COMPILER": "/opt/clang/bin/clang++",

        "CMAKE_C_FLAGS": "-g -O1 -fno-omit-frame-pointer -fsanitize=fuzzer,address,undefined",
        "CMAKE_CXX_FLAGS": "-g -O1 -fno-omit-frame-pointer -fsanitize=fuzzer,address,undefined",

        "CMAKE_EXE_LINKER_FLAGS": "-fsanitize=fuzzer,address,undefined",
        "CMAKE_SHARED_LINKER_FLAGS": "-fsanitize=fuzzer,address,undefined"
      }
    }
  ]
}

This is:

• portable

• preset-controlled

• commonly used by OSS-Fuzz-style setups

⚠️ Downside: applies to all targets in that build tree.

Option 2: Preset sets a mode, CMakeLists applies target options

(Most idiomatic CMake)

CMakePresets.json

json
Skopiuj kod
{
  "cacheVariables": {
    "ENABLE_FUZZING": "ON"
  }
}

CMakeLists.txt

cmake
Skopiuj kod
option(ENABLE_FUZZING "Enable fuzzing instrumentation" OFF)

add_executable(fuzz_processor fuzz_processor.cpp)

if (ENABLE_FUZZING)
    target_compile_options(fuzz_processor PRIVATE
        -g -O1 -fno-omit-frame-pointer
        -fsanitize=fuzzer,address,undefined
    )
    target_link_options(fuzz_processor PRIVATE
        -fsanitize=fuzzer,address,undefined
    )
endif()

✅ Best balance of:

• clean presets

• target-level precision

• reusable project logic

This is the approach I’d recommend for anything non-trivial.

Option 3: Use a toolchain file (advanced / CI-friendly)

Preset points to a toolchain file:

json
Skopiuj kod
{
  "cacheVariables": {
    "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/cmake/fuzz-toolchain.cmake"
  }
}

And in fuzz-toolchain.cmake:

cmake
Skopiuj kod
set(CMAKE_C_COMPILER clang)
set(CMAKE_CXX_COMPILER clang++)

set(CMAKE_C_FLAGS_INIT "-fsanitize=fuzzer,address,undefined")
set(CMAKE_CXX_FLAGS_INIT "-fsanitize=fuzzer,address,undefined")
set(CMAKE_EXE_LINKER_FLAGS_INIT "-fsanitize=fuzzer,address,undefined")

Used heavily in cross-compilation and hermetic builds.

What you should not do

❌ Don’t try to:

• encode target logic into presets

• overload CMAKE_<LANG>_FLAGS for fine-grained per-target control

• mix sanitizers across different presets without isolating build directories

Recommendation for your fuzzing setup

Given your earlier context (libFuzzer, portable clang, Ubuntu 22.04):

✔ Use Option 2:

• Preset selects mode (ENABLE_FUZZING=ON)

• CMakeLists.txt owns target logic

• Clean, debuggable, future-proof

If you want, I can:

• refactor your existing CMakeLists to be fuzz-ready

• design a multi-preset layout (debug, release, fuzz)

• show how to avoid sanitizer flags leaking into non-fuzz targets

Just tell me what you want next.

Yes — you can run a fuzz target “through CMake” in a few practical ways. CMake won’t fuzz by itself, but it can build and launch the fuzzer via ctest or a custom target.

Option A: Run it with CTest (recommended)

In CMakeLists.txt:

cmake
Skopiuj kod
enable_testing()

add_test(
  NAME fuzz_processor_smoke
  COMMAND fuzz_processor
          -runs=1000
          -max_len=4096
)

Then:

bash
Skopiuj kod
cmake --build <build_dir> --target fuzz_processor
ctest --test-dir <build_dir> -R fuzz_processor_smoke --output-on-failure

Why this is nice:

• works with presets (cmake --preset … then ctest --preset …)

• you can keep it as a smoke test (limited runs/time) for CI

Tip: In CI, prefer -max_total_time=60 (or similar) instead of infinite fuzzing.

Option B: Add a custom CMake target that runs the fuzzer

cmake
Skopiuj kod
add_custom_target(run_fuzz_processor
  COMMAND $<TARGET_FILE:fuzz_processor>
          -max_total_time=60
          -artifact_prefix=${CMAKE_BINARY_DIR}/fuzz_artifacts/
  DEPENDS fuzz_processor
  USES_TERMINAL
)

Run:

bash
Skopiuj kod
cmake --build <build_dir> --target run_fuzz_processor

This is the closest to “run through CMake build”.

Option C: Use cmake --build --target test (CTest default)

If you used Option A (add_test), you can also do:

bash
Skopiuj kod
cmake --build <build_dir> --target test

(That’s equivalent to running CTest in many generators; Ninja/MSBuild behaviors vary slightly.)

Good defaults for fuzzers in CTest/CI

A fuzzer normally runs forever, so for automation give it bounds:

• -runs=10000 (fixed iterations) or

• -max_total_time=60 (fixed time)

• -timeout=5 (per-input timeout) if you suspect hangs

Example CI-friendly command:

cmake
Skopiuj kod
add_test(NAME fuzz_processor_ci
  COMMAND fuzz_processor
          -max_total_time=60
          -timeout=5
          -artifact_prefix=${CMAKE_BINARY_DIR}/fuzz_artifacts/
)

Using presets to run it cleanly

If you have a build preset fuzz:

bash
Skopiuj kod
cmake --preset fuzz
cmake --build --preset fuzz --target fuzz_processor
ctest --preset fuzz -R fuzz_processor_ci --output-on-failure

(CTest presets live in the same CMakePresets.json under testPresets.)

If you paste your current CMakePresets.json (or just the relevant preset), I can write a matching testPresets block + a ready add_test()/add_custom_target() setup tailored to your exact build dir and target name.

Yep—there are several other solid ways to “run” a libFuzzer target via CMake tooling, depending on what you mean by through CMake (build system integration, IDE integration, install/run, CI, etc.). Here are more options beyond add_test() and a custom run_* target.

Option D: Use cmake --build with --target that runs ctest presets

If you already define tests, some generators let you do:

bash
Skopiuj kod
cmake --build <build_dir> --target test

This triggers CTest from the build system. It’s not perfect across all generators, but it’s common (Ninja/Makefiles).

Option E: Add a “driver” executable target that wraps libFuzzer flags

Create a tiny runner program or script target that calls your fuzzer with standardized flags (time limit, corpus, artifacts). Then CMake runs the runner.

Example (CMake + script):

cmake
Skopiuj kod
configure_file(${CMAKE_SOURCE_DIR}/cmake/run_fuzz_processor.sh.in
               ${CMAKE_BINARY_DIR}/run_fuzz_processor.sh @ONLY)

add_custom_target(run_fuzz_processor_script
  COMMAND /bin/sh ${CMAKE_BINARY_DIR}/run_fuzz_processor.sh
  DEPENDS fuzz_processor
  USES_TERMINAL
)

run_fuzz_processor.sh.in could set ASAN_OPTIONS, create corpus dirs, set LLVM_SYMBOLIZER, etc. This keeps CMakeLists clean and moves “policy” into a script.

Option F: Use CMake presets’ buildPresets + testPresets to run fuzzing in one command line

This is still CTest, but the difference is you can make a dedicated test preset that runs your fuzzer with arguments and env vars.

In CMakePresets.json you can define testPresets with:

• environment (ASAN_OPTIONS, UBSAN_OPTIONS, LLVM_SYMBOLIZER)

• filter (include regex for just fuzz tests)

• output controls

Then:

bash
Skopiuj kod
ctest --preset fuzz

It feels like “running via presets” and works nicely in CI/IDE.

Option G: Use install(TARGETS ...) and run from an installed prefix

If you want “build + install + run” as a standard workflow:

cmake
Skopiuj kod
install(TARGETS fuzz_processor RUNTIME DESTINATION bin)

Then:

bash
Skopiuj kod
cmake --build <build_dir> --target install
<install_prefix>/bin/fuzz_processor -max_total_time=60

This is handy if you ship the fuzzer into a container/image where runtime env is clean.

Option H: Add a fuzz “meta target” that builds multiple fuzzers

If you have many fuzz targets, you can define a meta target that depends on all fuzz executables:

cmake
Skopiuj kod
add_custom_target(fuzz_targets)
add_dependencies(fuzz_targets fuzz_processor fuzz_parser fuzz_decoder)

Then:

bash
Skopiuj kod
cmake --build <build_dir> --target fuzz_targets

Combine with one runner script/ctest preset to execute whichever you want.

Option I: Integrate with CTest labels + -L selection

Label fuzz tests and run them selectively:

cmake
Skopiuj kod
set_tests_properties(fuzz_processor_ci PROPERTIES LABELS "fuzz")

Run:

bash
Skopiuj kod
ctest --test-dir <build_dir> -L fuzz

Great when fuzz smoke tests live alongside unit tests.

Option J: Use ExternalProject / FetchContent style “superbuild” to run fuzzing isolated

If you really want isolation (no “leaking” sanitizer flags into normal builds), you can make a separate fuzz build configured from the main build:

• main build stays clean

• fuzz build is a separate CMake invocation managed by CMake

This is heavier, but it’s a legit “CMake runs fuzz build” workflow for large repos.

What I’d pick in practice

• Single fuzzer / local dev: custom run_fuzz_* target or script target (Option B/E)

• CI smoke fuzzing: CTest test + label + time limit (Option A/I)

• Many fuzzers: meta target + label-based selection (Option H/I)

• Strict isolation: separate fuzz build tree / superbuild (Option J)

If you tell me which you want (local dev, CI, many fuzzers, isolation), I’ll write the exact CMake + preset snippets for your setup.

You can put a lot into CMakePresets.json, but there’s a hard limit: presets can only set cache variables / environment / generator / build & test invocations. They cannot create targets or attach target_compile_options() to an existing target without changing CMakeLists.

So the “max you can do with only presets” is:

1. configure compilers + global flags (compile + link)

2. build the fuzz target by name

3. run it via a testPreset (without adding add_test) using ctest “dashboard/script” mode isn’t great; instead, use a buildPreset + a workflowPreset to run commands? (CMake has limited command-running in presets). Practically, you run the executable using cmake --build and then invoke it yourself, unless you already have tests defined.

The best compromise that keeps all fuzz flags out of CMakeLists is:

• Use presets to inject global sanitizer/fuzzer flags

• Build the fuzz target (which must already exist)

• Run it from the command line (or from IDE “launch” config, not CMake)

If your fuzz target already exists as fuzz_processor, here’s the “all in presets” setup.

A “mostly everything in presets” CMakePresets.json

This does:

• portable clang in /opt/clang

• global libFuzzer + ASan + UBSan flags

• environment for symbolization and sanitizer behavior

• build preset that builds only fuzz_processor

• test preset that runs CTest if you already have tests (optional)

json
Skopiuj kod
{
  "version": 6,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 23,
    "patch": 0
  },
  "configurePresets": [
    {
      "name": "fuzz",
      "displayName": "Fuzz (clang + libFuzzer + ASan/UBSan)",
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build-fuzz",
      "cacheVariables": {
        "CMAKE_C_COMPILER": "/opt/clang/bin/clang",
        "CMAKE_CXX_COMPILER": "/opt/clang/bin/clang++",
        "CMAKE_BUILD_TYPE": "RelWithDebInfo",

        "CMAKE_C_FLAGS": "-g -O1 -fno-omit-frame-pointer -fsanitize=fuzzer,address,undefined",
        "CMAKE_CXX_FLAGS": "-g -O1 -fno-omit-frame-pointer -fsanitize=fuzzer,address,undefined",

        "CMAKE_EXE_LINKER_FLAGS": "-fsanitize=fuzzer,address,undefined",
        "CMAKE_SHARED_LINKER_FLAGS": "-fsanitize=fuzzer,address,undefined",
        "CMAKE_MODULE_LINKER_FLAGS": "-fsanitize=fuzzer,address,undefined"
      },
      "environment": {
        "LLVM_SYMBOLIZER": "/opt/clang/bin/llvm-symbolizer",
        "ASAN_OPTIONS": "abort_on_error=1:detect_leaks=0:handle_abort=1:symbolize=1",
        "UBSAN_OPTIONS": "halt_on_error=1:abort_on_error=1:print_stacktrace=1:symbolize=1"
      }
    }
  ],
  "buildPresets": [
    {
      "name": "fuzz-build",
      "displayName": "Build fuzz_processor",
      "configurePreset": "fuzz",
      "targets": [ "fuzz_processor" ],
      "jobs": 0
    }
  ],
  "testPresets": [
    {
      "name": "fuzz-test",
      "displayName": "Run ctest (if fuzz tests are registered)",
      "configurePreset": "fuzz",
      "output": { "outputOnFailure": true }
    }
  ]
}

How you use it

bash
Skopiuj kod
cmake --preset fuzz
cmake --build --preset fuzz-build

Now run the fuzzer executable directly:

bash
Skopiuj kod
./out/build-fuzz/fuzz_processor -max_total_time=60 -artifact_prefix=./out/build-fuzz/artifacts/

Why you can’t fully avoid CMakeLists changes (one unavoidable bit)

If you want “run fuzz target through cmake/ctest using presets only”, then the fuzz run must be a CTest test. But CTest only knows about tests that were registered via add_test() (or generated by a framework integration). Without some CMakeLists logic, CTest has nothing to run.

So either:

• (A) accept running the fuzzer executable directly (still fully configured by presets), or

• (B) add a tiny add_test() line (one-line change) and then you can run via ctest --preset …

You said you want to avoid changing CMakeLists, so A is the max possible.

One more trick: keep flags scoped without changing targets

If you don’t want sanitizers to affect all targets, keep fuzzing in a separate build tree (as above: out/build-fuzz). That gives you clean separation with no CMakeLists changes.

If you tell me:

• the exact name of your fuzz executable target (e.g. fuzz_processor?)

• where your portable clang lives (/opt/clang is OK?)

• whether you want ASan leak detection on/off

…I’ll tailor the presets to your project exactly (still without toolchain files or CMakeLists edits).

In practice, the most widely used pattern today is both — with different jobs:

• Toolchain files are the “portable, reusable definition of a compiler + sysroot + ABI”.

• CMakePresets.json are the “developer/CI entry points” that pick a toolchain, build dir, and a few toggles.

If I had to rank what’s most common across real projects:

1. Toolchain files (especially for cross-compiling, embedded, reproducible builds)

2. Presets (increasingly common since IDEs and CI started supporting them well)

3. Plain old -D... command lines (still extremely common in older repos)

When CMakePresets are the better default

Use Presets when you want:

• consistent configure/build commands for humans + CI

• multiple build variants (debug/release/asan/ubsan/fuzz) with different build dirs

• per-user overrides via CMakeUserPresets.json (local paths to clang, SDKs, etc.)

• minimal “CMake code” changes (you can inject flags with cache vars)

Great for your fuzzing workflow if you’re OK with:

• global flags per build tree (sanitizers apply to everything in that build dir)

• running fuzzers directly unless you already have add_test()

When toolchain files are the better default

Use a toolchain file when you care about:

• true portability / reproducibility of the toolchain definition

• cross-compiling (almost mandatory)

• consistent compiler + linker + sysroot + CMake “try_compile” behavior

• avoiding fragile global flag injection (CMAKE_CXX_FLAGS, etc.)

• sharing the exact toolchain setup across repos

For “portable clang distribution” + fuzzing, toolchain files help when:

• you need to bundle libc++ / runtime choices

• you want to pin exactly how CMake detects and uses the compiler

The most pragmatic recommendation

Use presets for selection + toolchains for definition.

Example pattern:

• cmake/toolchains/clang-fuzz.cmake defines compilers + sanitizer instrumentation policy

• CMakePresets.json chooses build dirs and sets CMAKE_TOOLCHAIN_FILE + a couple toggles

This scales best and is what you’ll see in many modern CMake repos.

If you insist on “presets only”

It’s workable and common for single-platform projects:

• Put compilers and flags in presets (CMAKE_CXX_COMPILER, CMAKE_CXX_FLAGS, linker flags)

• Use separate build dirs per preset to avoid “flag leakage”

Just know the ceiling:

• presets can’t do per-target options

• presets can’t invent a fuzz “run” unless the project already registers tests (CTest)

Quick decision table

What I’d do for your libFuzzer setup

• If it’s just Ubuntu and you want minimal files: Presets-only is fine.

• If you want this to be robust, shareable, and grow (more fuzzers, CI, maybe different clang versions): toolchain + presets.

If you paste your current CMakePresets.json, I can suggest a clean structure (still minimal) for debug, release, and fuzz variants that won’t contaminate each other.

That’s the most maintainable setup in 2026 CMake-land: small Presets, “real” settings in toolchain files.

Recommended layout

pgsql
Skopiuj kod
CMakePresets.json
cmake/
  toolchains/
    clang-fuzz.cmake
    clang-asan.cmake
    clang-release.cmake

Toolchain files hold:

• compiler paths (portable clang in /opt/clang or versioned dir)

• sanitizer/fuzzer flags

• env helpers (symbolizer, etc.) as CMake cache defaults

Presets stay concise:

• generator

• binaryDir

• which toolchain

• build/test presets

Clean, concise CMakePresets.json

json
Skopiuj kod
{
  "version": 6,
  "configurePresets": [
    {
      "name": "base",
      "hidden": true,
      "generator": "Ninja",
      "cacheVariables": {
        "CMAKE_EXPORT_COMPILE_COMMANDS": "ON"
      }
    },
    {
      "name": "fuzz",
      "inherits": "base",
      "binaryDir": "${sourceDir}/out/build-fuzz",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "RelWithDebInfo",
        "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/cmake/toolchains/clang-fuzz.cmake"
      }
    }
  ],
  "buildPresets": [
    {
      "name": "fuzz",
      "configurePreset": "fuzz",
      "targets": [ "fuzz_processor" ],
      "jobs": 0
    }
  ]
}

Usage:

bash
Skopiuj kod
cmake --preset fuzz
cmake --build --preset fuzz
./out/build-fuzz/fuzz_processor -max_total_time=60

(If you later add add_test, you can add a tiny testPresets block too.)

Example toolchain: cmake/toolchains/clang-fuzz.cmake

cmake
Skopiuj kod
# clang-fuzz.cmake
# Toolchain file for clang + libFuzzer + ASan/UBSan.
# Keep it deterministic and repo-friendly.

set(CMAKE_C_COMPILER   "/opt/clang/bin/clang"   CACHE FILEPATH "" FORCE)
set(CMAKE_CXX_COMPILER "/opt/clang/bin/clang++" CACHE FILEPATH "" FORCE)

# Recommend Ninja with clang; not required.
# set(CMAKE_MAKE_PROGRAM "/usr/bin/ninja" CACHE FILEPATH "" FORCE)

# Common flags for fuzzing
set(_FUZZ_COMMON "-g -O1 -fno-omit-frame-pointer")

# libFuzzer is linked via -fsanitize=fuzzer; combine with sanitizers
set(_FUZZ_SAN "-fsanitize=fuzzer,address,undefined")

set(CMAKE_C_FLAGS_INIT   "${_FUZZ_COMMON} ${_FUZZ_SAN}")
set(CMAKE_CXX_FLAGS_INIT "${_FUZZ_COMMON} ${_FUZZ_SAN}")

# Linker flags (executables are what fuzzers are)
set(CMAKE_EXE_LINKER_FLAGS_INIT "${_FUZZ_SAN}")

# Helpful runtime env for better stacks (you still export these in your shell/CI)
# CMake itself can't reliably “export env at runtime” for arbitrary executables,
# but it can help CTest (if you later run via add_test/ctest).
set(ENV{LLVM_SYMBOLIZER} "/opt/clang/bin/llvm-symbolizer")
set(ENV{ASAN_OPTIONS} "abort_on_error=1:detect_leaks=0:handle_abort=1:symbolize=1")
set(ENV{UBSAN_OPTIONS} "halt_on_error=1:abort_on_error=1:print_stacktrace=1:symbolize=1")

Notes

• Using *_FLAGS_INIT is toolchain-friendly: it seeds flags early, before most checks.

• For fuzzing, I’d keep leak detection off by default (detect_leaks=0) unless you explicitly want it (LSan can slow fuzzing and produce noise).

Extra: keep paths out of git (optional but common)

If /opt/clang differs per dev machine, don’t hardcode it in the toolchain. Two clean patterns:

Pattern A: environment variable

cmake
Skopiuj kod
if(DEFINED ENV{LLVM_HOME})
  set(_LLVM_HOME "$ENV{LLVM_HOME}")
else()
  set(_LLVM_HOME "/opt/clang")
endif()

set(CMAKE_C_COMPILER   "${_LLVM_HOME}/bin/clang" CACHE FILEPATH "" FORCE)
set(CMAKE_CXX_COMPILER "${_LLVM_HOME}/bin/clang++" CACHE FILEPATH "" FORCE)

Pattern B: per-user preset override

• Commit CMakePresets.json

• Each dev has CMakeUserPresets.json with their local toolchain path

This keeps repo config clean and avoids “works on my machine”.

My recommendation for you

• Yes: keep CMakePresets.json small

• Yes: store compiler + sanitizer/fuzzer policy in toolchain files

• Also: if you want “run fuzz via ctest”, add a single add_test() later; otherwise run the fuzzer executable directly

If you tell me whether your portable clang lives at /opt/clang or versioned like /opt/llvm/17, I’ll tailor the toolchain file so it’s robust and doesn’t require edits when you upgrade LLVM.

Yes — it can be set in a toolchain file, but whether you should do it depends on how you use CMake. This is one of those “allowed, but sharp edges” areas.

Let’s be precise.

The factual answer

✔ Yes, you can set CMAKE_BUILD_TYPE in a toolchain file, e.g.:

cmake
Skopiuj kod
set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "" FORCE)

CMake will honor it for single-config generators (Ninja, Makefiles).

But here’s the important nuance

Toolchain files are meant to define:

• compiler

• sysroot / SDK

• ABI

• platform properties

CMAKE_BUILD_TYPE defines:

• build configuration, not toolchain

• optimization / debug policy

That mismatch is why setting it in a toolchain file is legal but controversial.

When it’s reasonable to do it

Setting CMAKE_BUILD_TYPE in a toolchain file makes sense when:

• you use single-config generators only (Ninja/Makefiles)

• the build type is inseparable from the toolchain
  (e.g. “this is a fuzz toolchain”)

Example: a fuzz toolchain that must always be RelWithDebInfo.

cmake
Skopiuj kod
# clang-fuzz.cmake
set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "" FORCE)

This guarantees:

• no accidental Debug builds with slow fuzzing

• reproducible behavior across machines and CI

This pattern is used in fuzzing and sanitizer setups.

When you should NOT do it

❌ Avoid setting CMAKE_BUILD_TYPE in a toolchain file if:

• you use multi-config generators (Visual Studio, Xcode, Ninja Multi-Config)

• you want to switch Debug/Release without reconfiguring

• the same toolchain should support multiple build types

In multi-config generators:

• CMAKE_BUILD_TYPE is ignored

• configuration is chosen at build time (--config Debug)

• setting it in a toolchain file is meaningless or confusing

Best-practice recommendation (cleanest design)

Keep this separation:

This keeps:

• toolchains reusable

• presets readable

• behavior unsurprising

Example (recommended)

Toolchain

cmake
Skopiuj kod
# clang-fuzz.cmake
set(CMAKE_C_COMPILER   "/opt/clang/bin/clang"   CACHE FILEPATH "" FORCE)
set(CMAKE_CXX_COMPILER "/opt/clang/bin/clang++" CACHE FILEPATH "" FORCE)

set(_SAN "-fsanitize=fuzzer,address,undefined")
set(CMAKE_C_FLAGS_INIT   "${_SAN}")
set(CMAKE_CXX_FLAGS_INIT "${_SAN}")
set(CMAKE_EXE_LINKER_FLAGS_INIT "${_SAN}")

Preset

json
Skopiuj kod
{
  "cacheVariables": {
    "CMAKE_BUILD_TYPE": "RelWithDebInfo",
    "CMAKE_TOOLCHAIN_FILE": "cmake/toolchains/clang-fuzz.cmake"
  }
}

This is the most common and least surprising setup in modern CMake projects.

A compromise pattern (used by some teams)

If you really want the toolchain to provide a default but allow override:

cmake
Skopiuj kod
if(NOT DEFINED CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "" FORCE)
endif()

This:

• sets a sane default

• still allows presets or CLI to override it

Bottom line

• ✔ Possible: yes

• ⚠️ Recommended: only if the build type is intrinsic to the toolchain (fuzzing often is)

• ✅ Best practice: toolchain = how you build, preset = what you build

If you want, I can:

• review your current toolchain file for sharp edges

• suggest naming conventions (clang-fuzz, clang-asan, etc.)

• show how to make this work cleanly with Ninja Multi-Config

Just say the word.

You can define how fuzz tests are run in a testPreset, but not what they are.

That distinction is the key constraint.

The hard limit (cannot be bypassed)

❌ testPresets cannot invent or define tests.
CTest only runs tests that were registered at configure time via:

cmake
Skopiuj kod
add_test(NAME ... COMMAND ...)

So:

• testPreset ✅ controls how CTest runs

• testPreset ❌ cannot define what command is a test

This is a fundamental CMake/CTest rule.

👉 Therefore: at least one add_test() must exist somewhere
(one line is enough; no toolchain or logic needed).

Minimal, acceptable CMakeLists change (one-liner)

If your fuzz target already exists as fuzz_processor, this is literally all you need:

cmake
Skopiuj kod
add_test(NAME fuzz_processor COMMAND fuzz_processor)

That’s it.
No flags, no logic, no presets involved.

Everything else goes into CMakePresets.json.

Now: defining fuzz execution in testPreset (your goal)

Once the test exists, you can fully define fuzz execution behavior in testPresets.

Example testPresets for fuzzing

json
Skopiuj kod
{
  "testPresets": [
    {
      "name": "fuzz",
      "displayName": "Run fuzz tests (time-bounded)",
      "configurePreset": "fuzz",
      "filter": {
        "include": {
          "name": "fuzz_.*"
        }
      },
      "execution": {
        "timeoutSeconds": 300
      },
      "environment": {
        "LLVM_SYMBOLIZER": "/opt/clang/bin/llvm-symbolizer",
        "ASAN_OPTIONS": "abort_on_error=1:detect_leaks=0:symbolize=1",
        "UBSAN_OPTIONS": "halt_on_error=1:abort_on_error=1:print_stacktrace=1"
      },
      "output": {
        "outputOnFailure": true
      }
    }
  ]
}

Run it with:

bash
Skopiuj kod
ctest --preset fuzz

How do fuzz flags get passed?

There are three valid patterns. Pick one.

Pattern A (cleanest): encode fuzz limits in add_test

cmake
Skopiuj kod
add_test(
  NAME fuzz_processor
  COMMAND fuzz_processor
          -max_total_time=60
          -timeout=5
          -artifact_prefix=${CMAKE_BINARY_DIR}/fuzz_artifacts/
)

Pros:

• deterministic

• CI-friendly

• fully controlled by CTest + presets

Cons:

• flags live in CMakeLists

Pattern B (advanced): use CTEST_PARALLEL_LEVEL + env only

Let the test run “normally”, but control behavior via environment:

json
Skopiuj kod
"environment": {
  "LIBFUZZER_OPTIONS": "-max_total_time=60 -timeout=5"
}

And in your fuzzer main:

cpp
Skopiuj kod
const char* opts = std::getenv("LIBFUZZER_OPTIONS");
// parse or forward as needed

⚠️ This requires custom code and is not common.

Pattern C (hybrid, common in CI)

• add_test(NAME fuzz_processor COMMAND fuzz_processor)

• limit runtime using CTest timeout

• rely on sanitizer aborts to fail the test

This is widely used for “fuzz smoke tests”.

What testPreset is excellent for

Once the test exists, presets shine at:

✅ selecting fuzz-only tests (filter.include.name)
✅ setting sanitizer + symbolizer env
✅ bounding runtime (timeoutSeconds)
✅ CI vs local variants
✅ keeping CMakeLists clean and boring

What is NOT possible (by design)

❌ Define a test command in testPreset
❌ Attach arguments to a specific test from testPreset
❌ Run arbitrary executables via ctest without add_test

This is not a missing feature — it’s a deliberate design choice in CMake.

Recommendation for your stated goals

You want:

• clean CMakePresets.json

• logic in toolchains

• minimal CMakeLists noise

• fuzz execution defined via presets

➡ Best achievable design:

1. One-line add_test() per fuzz target

2. Everything else in testPresets

3. Separate fuzz build tree

This is exactly how many large CMake + fuzz projects do it.

If you want, next I can:

• show a naming convention (fuzz_*) that scales to many fuzzers

• design two testPresets: fuzz-smoke (CI) vs fuzz-long

• explain how OSS-Fuzz maps onto this model

Just say what you want next.

Yep — you can make this smooth in CLion, but there’s one key reality:

CLion can run CTest tests and CMake targets easily, and it can run an executable with args easily — but CTest tests still have to exist in CMakeLists (even if it’s just one-liners). Presets can’t define tests.

Here’s the cleanest setup that keeps presets/toolchains doing the heavy lifting and makes CLion “one click run”.

Best approach for CLion: CTest + CMake Presets

1) Minimal CMakeLists additions (small, scalable)

Assuming your fuzz targets are already defined (e.g. add_executable(fuzz_processor ...)), add only:

cmake
Skopiuj kod
enable_testing()
add_test(NAME fuzz_processor COMMAND $<TARGET_FILE:fuzz_processor>)
set_tests_properties(fuzz_processor PROPERTIES LABELS fuzz)

That gives CLion something it can discover and run under Tests.

If you have many fuzzers, repeat the add_test line per target (or use a small helper macro if you ever relax the “no CMake code” rule).

2) Put the “fuzz run policy” in CMakePresets.json testPresets

You have two practical ways:

A) CI/smoke style: bound by CTest timeout (no fuzzer args needed)

json
Skopiuj kod
{
  "testPresets": [
    {
      "name": "fuzz-smoke",
      "displayName": "Fuzz smoke (CTest timeout)",
      "configurePreset": "fuzz",
      "filter": { "include": { "label": "fuzz" } },
      "execution": { "timeoutSeconds": 60 },
      "environment": {
        "LLVM_SYMBOLIZER": "/opt/clang/bin/llvm-symbolizer",
        "ASAN_OPTIONS": "abort_on_error=1:detect_leaks=0:symbolize=1",
        "UBSAN_OPTIONS": "halt_on_error=1:abort_on_error=1:print_stacktrace=1:symbolize=1"
      },
      "output": { "outputOnFailure": true }
    }
  ]
}

Pros: CMakeLists stays clean (no args embedded)
Cons: libFuzzer will run “forever”, and CTest will just kill it at 60s (fine for smoke).

B) “Proper” fuzzing: pass libFuzzer args in the test command (recommended)

This is the only way to reliably control -max_total_time, corpus dirs, artifacts, etc. without extra scripts.

cmake
Skopiuj kod
add_test(NAME fuzz_processor
  COMMAND $<TARGET_FILE:fuzz_processor>
          -max_total_time=60
          -timeout=5
          -artifact_prefix=${CMAKE_BINARY_DIR}/fuzz_artifacts/
          ${CMAKE_SOURCE_DIR}/fuzz/corpus/processor
)
set_tests_properties(fuzz_processor PROPERTIES LABELS fuzz)

Then the same testPreset just selects label fuzz.

Pros: best developer experience + reproducible behavior
Cons: a few args live in CMakeLists (but it’s still minimal and very maintainable)

Running from CLion (what to do)

Use CLion’s CMake Presets support

1. Settings / Preferences → Build, Execution, Deployment → CMake

2. Enable CMake Presets (and choose your fuzz configure preset as a profile)

3. Reload CMake

Now CLion will:

• configure using your fuzz preset (clang + sanitizers from toolchain)

• show tests under Tests tool window (CTest)

Run fuzzers from CLion with one click

• Open Tests tool window

• Find fuzz_processor (or filter by label if CLion shows labels)

• Click Run / Debug

If you used pattern B (args in add_test), you’re done: it will run bounded fuzzing.

Alternative CLion workflow: Run configuration for the fuzzer executable

If you truly want zero args in CMakeLists, you can:

• create a CLion “Application” run config for fuzz_processor

• set program args there (-max_total_time=60 ...)

Pros: no CMakeLists changes beyond add_executable
Cons: run configs are per-user / IDE state unless you export/share them; not great for team/CI consistency.

My recommendation for your goals

You said:

• keep CMakePresets.json clean

• keep settings in toolchain files

• run easily from CLion

The best “team friendly + CLion friendly” setup is:

• Toolchain file contains compilers + sanitizer/fuzzer flags

• Preset selects toolchain + build dir

• CTest test exists for each fuzzer

• Put fuzzer args in add_test (just the minimal stable ones: time limit, artifact prefix, corpus path)

• Use testPreset to select label fuzz and set sanitizer env

That gives you:

• one-click run in CLion

• consistent behavior in CI

• minimal growth of presets and CMakeLists

If you tell me:

• your fuzz target name(s)

• whether you have a corpus directory (and where you want it)

• whether you want CI smoke (60s) + local longer run

…I’ll output an exact minimal snippet (CMakeLists + Presets) tailored to your paths and conventions.

Yes — absolutely.
Once a fuzz target is registered with add_test(), you can give each test its own parameters, including libFuzzer options like -max_total_time.

There are three clean, idiomatic ways to do this in CMake.

✅ 1) Pass libFuzzer parameters directly in add_test (most common)

This is the most widely used and the simplest.

cmake
Skopiuj kod
add_test(
  NAME fuzz_processor_smoke
  COMMAND $<TARGET_FILE:fuzz_processor>
          -max_total_time=30
          -timeout=5
          -artifact_prefix=${CMAKE_BINARY_DIR}/fuzz_artifacts/
)

You can define multiple tests for the same fuzzer:

cmake
Skopiuj kod
add_test(
  NAME fuzz_processor_long
  COMMAND $<TARGET_FILE:fuzz_processor>
          -max_total_time=600
          -timeout=10
)

Then select which one to run via:

• test name

• labels

• testPreset filters

✔ different -max_total_time
✔ different corpus paths
✔ different artifact directories
✔ fully reproducible
✔ CLion-friendly

This is the recommended approach for libFuzzer.

✅ 2) Use set_tests_properties() to control execution limits

This does not pass libFuzzer flags, but controls CTest behavior.

cmake
Skopiuj kod
add_test(NAME fuzz_processor COMMAND $<TARGET_FILE:fuzz_processor>)

set_tests_properties(fuzz_processor PROPERTIES
  TIMEOUT 60          # seconds; CTest kills the process
  LABELS fuzz
)

What this means:

• libFuzzer still runs “forever”

• CTest forcibly stops it after 60s

• test is considered failed if killed

This is commonly used for CI smoke fuzzing.

⚠️ Limitation:

• you cannot control libFuzzer internals (corpus, artifact prefix, per-input timeout)

✅ 3) Set per-test environment variables (advanced)

You can also set environment variables per test:

cmake
Skopiuj kod
set_tests_properties(fuzz_processor PROPERTIES
  ENVIRONMENT
    "ASAN_OPTIONS=abort_on_error=1:detect_leaks=0"
    "UBSAN_OPTIONS=halt_on_error=1"
)

This is useful for:

• sanitizer tuning

• symbolizer paths

• suppressions

⚠️ libFuzzer does NOT read options from env vars by default
(-max_total_time must still be a command-line arg).

🔁 Combine all three (real-world pattern)

cmake
Skopiuj kod
add_test(
  NAME fuzz_processor_ci
  COMMAND $<TARGET_FILE:fuzz_processor>
          -max_total_time=60
          -timeout=5
          -artifact_prefix=${CMAKE_BINARY_DIR}/fuzz_artifacts/
)

set_tests_properties(fuzz_processor_ci PROPERTIES
  LABELS fuzz
  TIMEOUT 70
  ENVIRONMENT
    "ASAN_OPTIONS=abort_on_error=1:detect_leaks=0:symbolize=1"
    "UBSAN_OPTIONS=halt_on_error=1:print_stacktrace=1"
)

This gives you:

• deterministic fuzzing behavior

• safety net timeout

• clean CI + CLion integration

How this plays with testPresets and CLion

Once tests exist:

• testPresets can:

  • select which fuzz tests to run (by name or label)

  • define sanitizer env globally

  • bound execution time further if desired

json
Skopiuj kod
"filter": {
  "include": { "label": "fuzz" }
}

In CLion:

• tests appear in the Tests tool window

• you can run fuzz_processor_ci or fuzz_processor_long with one click

Recommendation for your setup

Given your goals (clean presets, toolchains for config, CLion-friendly):

✔ Put libFuzzer parameters in add_test()
✔ Use multiple tests per fuzzer for different modes (smoke vs long)
✔ Use labels to select via testPresets
✔ Keep presets focused on selection, not per-test behavior

This is the most scalable and least surprising approach.

If you want, I can:

• suggest a naming convention (fuzz_*_smoke, fuzz_*_long)

• show how to auto-generate fuzz tests from a list of targets

• help keep artifact/corpus dirs tidy per test

Just tell me what you want next.

Yes — you can avoid hardcoding libFuzzer params in CMake files and control them “from above”, but with one key constraint:

• CTest/testPresets cannot change a test’s command-line arguments directly.

• So you need the test command in CMake to reference variables (cache vars / env), and then you set those vars from CMakePresets.json.

That gives you a clean, scalable “higher-level control” with minimal CMake changes.

Best pattern: test command reads args from cache variable

Minimal CMake code (stable, not hardcoded)

cmake
Skopiuj kod
enable_testing()

# A cache var you control from presets/CLI.
set(FUZZER_ARGS "" CACHE STRING "Extra args passed to libFuzzer targets")

# Turn a space-separated string into a CMake list (so it becomes proper argv)
separate_arguments(FUZZER_ARGS)

add_test(
  NAME fuzz_processor
  COMMAND $<TARGET_FILE:fuzz_processor> ${FUZZER_ARGS}
)

set_tests_properties(fuzz_processor PROPERTIES LABELS fuzz)

What this achieves

• CMakeLists contains no policy values like -max_total_time=60

• It just says: “run this fuzzer with whatever args higher level provides”

Control it from CMakePresets.json

Example: testPresets sets the args (via cache at configure time)

Because FUZZER_ARGS is a cache variable, you set it in the configure preset (not test preset):

json
Skopiuj kod
{
  "version": 6,
  "configurePresets": [
    {
      "name": "fuzz-smoke",
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build-fuzz-smoke",
      "cacheVariables": {
        "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/cmake/toolchains/clang-fuzz.cmake",
        "CMAKE_BUILD_TYPE": "RelWithDebInfo",
        "FUZZER_ARGS": "-max_total_time=30 -timeout=5 -artifact_prefix=out/build-fuzz-smoke/artifacts/"
      }
    },
    {
      "name": "fuzz-long",
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build-fuzz-long",
      "cacheVariables": {
        "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/cmake/toolchains/clang-fuzz.cmake",
        "CMAKE_BUILD_TYPE": "RelWithDebInfo",
        "FUZZER_ARGS": "-max_total_time=600 -timeout=10 -artifact_prefix=out/build-fuzz-long/artifacts/"
      }
    }
  ],
  "testPresets": [
    {
      "name": "fuzz-smoke",
      "configurePreset": "fuzz-smoke",
      "filter": { "include": { "label": "fuzz" } },
      "environment": {
        "LLVM_SYMBOLIZER": "/opt/clang/bin/llvm-symbolizer",
        "ASAN_OPTIONS": "abort_on_error=1:detect_leaks=0:symbolize=1",
        "UBSAN_OPTIONS": "halt_on_error=1:abort_on_error=1:print_stacktrace=1"
      },
      "output": { "outputOnFailure": true }
    },
    {
      "name": "fuzz-long",
      "configurePreset": "fuzz-long",
      "filter": { "include": { "label": "fuzz" } },
      "output": { "outputOnFailure": true }
    }
  ]
}

Run:

bash
Skopiuj kod
cmake --preset fuzz-smoke
cmake --build --preset fuzz-smoke
ctest --preset fuzz-smoke

or:

bash
Skopiuj kod
cmake --preset fuzz-long
cmake --build --preset fuzz-long
ctest --preset fuzz-long

This is the cleanest “higher-level control”: different presets = different fuzz parameters, no hardcoded values in CMake.

Notes and gotchas

• separate_arguments(FUZZER_ARGS) is important; otherwise CMake treats the whole string as one argument.

• Keeping separate build dirs (out/build-fuzz-smoke, out/build-fuzz-long) prevents cache collisions and keeps things reproducible.

• testPreset is still useful for env (ASAN_OPTIONS, symbolizer), filtering by label, output.

CLion workflow

CLion can work nicely with this setup:

• Choose the configure preset (smoke vs long) in CLion’s CMake profile/presets UI

• Then run the CTest test fuzz_processor from the Tests window

• The args come from that preset’s cache (FUZZER_ARGS)

So you get “one click run” and high-level control.

If you want, I can also show a variant where:

• FUZZER_ARGS is different per fuzzer (e.g. FUZZER_ARGS_processor, FUZZER_ARGS_parser)

• or where corpus directories are injected cleanly without hardcoding paths.

option() is CMake’s built-in way to define boolean feature switches that can be controlled from the “outside” (CLI, presets, cache, GUIs) without hard-coding behavior in CMakeLists.txt.

Given your goal (high-level control via presets, minimal CMake logic), this fits perfectly.

What option() does

cmake
Skopiuj kod
option(ENABLE_FUZZING "Enable fuzzing support" OFF)

This creates a cache variable:

• Name: ENABLE_FUZZING

• Type: BOOL

• Default: OFF

• User-configurable via:

  • -DENABLE_FUZZING=ON

  • CMakePresets.json

  • CLion / CMake GUI

Once defined, you use it like a normal variable:

cmake
Skopiuj kod
if (ENABLE_FUZZING)
  # fuzz-related logic
endif()

Why option() is better than raw cache variables

Compared to:

cmake
Skopiuj kod
set(ENABLE_FUZZING OFF CACHE BOOL "")

option():

• documents intent (description shows up in GUIs/CLion)

• provides a default

• is idiomatic and expected by CMake users

• avoids accidental type misuse

Minimal fuzz-friendly pattern using option()

This matches your “control from higher level” requirement.

CMakeLists.txt (small, policy-only)

cmake
Skopiuj kod
option(ENABLE_FUZZING "Enable fuzz targets" OFF)

enable_testing()

if (ENABLE_FUZZING)
  add_test(
    NAME fuzz_processor
    COMMAND $<TARGET_FILE:fuzz_processor> ${FUZZER_ARGS}
  )
  set_tests_properties(fuzz_processor PROPERTIES LABELS fuzz)
endif()

No hardcoded flags.
No build-type logic.
No toolchain logic.

Drive it from CMakePresets.json

json
Skopiuj kod
{
  "configurePresets": [
    {
      "name": "fuzz",
      "binaryDir": "${sourceDir}/out/build-fuzz",
      "cacheVariables": {
        "ENABLE_FUZZING": "ON",
        "FUZZER_ARGS": "-max_total_time=60 -timeout=5"
      }
    }
  ]
}

Now:

• fuzz tests exist only when ENABLE_FUZZING=ON

• arguments come from presets

• CMakeLists stays stable and clean

Advanced: multiple fuzz “modes” without code duplication

You can stack options:

cmake
Skopiuj kod
option(ENABLE_FUZZING "Enable fuzz tests" OFF)
option(FUZZ_LONG_RUN "Enable long-running fuzz tests" OFF)

cmake
Skopiuj kod
if (ENABLE_FUZZING)
  set(_args "${FUZZER_ARGS}")
  if (FUZZ_LONG_RUN)
    list(APPEND _args "-max_total_time=600")
  endif()

  add_test(NAME fuzz_processor COMMAND $<TARGET_FILE:fuzz_processor> ${_args})
endif()

Presets choose behavior:

json
Skopiuj kod
"cacheVariables": {
  "ENABLE_FUZZING": "ON",
  "FUZZ_LONG_RUN": "ON"
}

Important caveats (worth knowing)

1️⃣ option() is evaluated at configure time

Changing it requires reconfigure (which presets naturally do).

2️⃣ option() is global

It’s not target-scoped. That’s intentional: it represents build configuration, not per-target logic.

3️⃣ Boolean only

If you need structured values (paths, arg lists), use:

cmake
Skopiuj kod
set(FUZZER_ARGS "" CACHE STRING "libFuzzer arguments")

…and combine with option().

Recommended pattern (what you’re converging to)

This is exactly how large, well-maintained CMake projects stay sane.

If you want, I can:

• refactor a small example showing option() + presets + CLion flow end-to-end

• show how to keep options discoverable in CLion’s UI

• help you design a naming scheme that won’t get messy as fuzzers grow

Just say what you want next.

Here’s the clean CMake pattern for a custom target that runs fuzz tests, while keeping the parameters controlled from “higher level” (cache vars / presets), and keeping hardcoded args out of CMake as much as possible.

1) CMakeLists.txt: custom target run_fuzz

This assumes you already have a fuzzer executable target called fuzz_processor.

cmake
Skopiuj kod
# Enable/disable fuzz runner from outside (presets/CLI)
option(ENABLE_FUZZING "Enable fuzz targets and runners" OFF)

# libFuzzer args controlled from presets/CLI
set(FUZZER_ARGS "" CACHE STRING "Arguments passed to libFuzzer targets (space-separated)")
separate_arguments(FUZZER_ARGS)  # convert string -> list for correct argv splitting

# Optional: where to put crash artifacts
set(FUZZ_ARTIFACT_DIR "${CMAKE_BINARY_DIR}/fuzz_artifacts" CACHE PATH "Directory for fuzz artifacts")

if (ENABLE_FUZZING)
  # Ensure artifact dir exists before running
  add_custom_target(run_fuzz
    COMMAND ${CMAKE_COMMAND} -E make_directory "${FUZZ_ARTIFACT_DIR}"
    COMMAND $<TARGET_FILE:fuzz_processor>
            -artifact_prefix=${FUZZ_ARTIFACT_DIR}/
            ${FUZZER_ARGS}
    DEPENDS fuzz_processor
    USES_TERMINAL
    COMMENT "Running libFuzzer: fuzz_processor"
  )
endif()

How to run

bash
Skopiuj kod
cmake --build <build_dir> --target run_fuzz

This gives you “run through CMake” via the build system.

2) Control everything from CMakePresets.json

Example preset that keeps it clean:

json
Skopiuj kod
{
  "version": 6,
  "configurePresets": [
    {
      "name": "fuzz",
      "generator": "Ninja",
      "binaryDir": "${sourceDir}/out/build-fuzz",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "RelWithDebInfo",
        "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/cmake/toolchains/clang-fuzz.cmake",

        "ENABLE_FUZZING": "ON",
        "FUZZER_ARGS": "-max_total_time=60 -timeout=5 -max_len=4096",
        "FUZZ_ARTIFACT_DIR": "${sourceDir}/out/fuzz_artifacts/"
      }
    }
  ],
  "buildPresets": [
    {
      "name": "run-fuzz",
      "configurePreset": "fuzz",
      "targets": [ "run_fuzz" ]
    }
  ]
}

Run it end-to-end:

bash
Skopiuj kod
cmake --preset fuzz
cmake --build --preset run-fuzz

3) Multiple fuzz targets (optional “meta runner”)

If you have more fuzzers, you can create separate runners:

cmake
Skopiuj kod
add_custom_target(run_fuzz_processor
  COMMAND ${CMAKE_COMMAND} -E make_directory "${FUZZ_ARTIFACT_DIR}"
  COMMAND $<TARGET_FILE:fuzz_processor> -artifact_prefix=${FUZZ_ARTIFACT_DIR}/ ${FUZZER_ARGS}
  DEPENDS fuzz_processor
  USES_TERMINAL
)

…and a meta target:

cmake
Skopiuj kod
add_custom_target(run_all_fuzz)
add_dependencies(run_all_fuzz run_fuzz_processor run_fuzz_parser)

Then cmake --build --target run_all_fuzz.

Notes / gotchas

• add_custom_target() runs at build time, not test time (so it’s not CTest). That’s fine if your goal is “run via CMake”.

• separate_arguments() is important so FUZZER_ARGS gets split into real argv items.

• If you want different params per fuzzer, use per-target cache vars, e.g. FUZZER_ARGS_processor.

If you tell me your fuzz target names (one or many) and where you want corpus/artifacts, I’ll give you a neat multi-fuzzer setup that still keeps presets clean and avoids hardcoding.

Use libFuzzer’s optional initializer hook: LLVMFuzzerInitialize. It is called once, before the first LLVMFuzzerTestOneInput run. Put your init steps there.

Example (one-time init)

cpp
Skopiuj kod
#include <cstdint>
#include <cstddef>
#include <vector>
#include <mutex>

// Include your project headers
#include "processor.hpp"

// One-time init flag (extra safety if you ever call init lazily too)
static std::once_flag g_init_once;

static void DoInitOnce(int* argc, char*** argv) {
    // Put your init here, examples:
    // - set up logging
    // - seed deterministic RNG
    // - load configuration
    // - initialize singletons
    // - create temp dirs
    //
    // Keep it deterministic and avoid network / long I/O for fuzzing.
    (void)argc;
    (void)argv;

    // Example:
    // my_library::Init();
}

extern "C" int LLVMFuzzerInitialize(int* argc, char*** argv) {
    std::call_once(g_init_once, [&] { DoInitOnce(argc, argv); });
    return 0;
}

extern "C" int LLVMFuzzerTestOneInput(const std::uint8_t* data, std::size_t size) {
    // Optional: if you prefer lazy init instead of LLVMFuzzerInitialize:
    // std::call_once(g_init_once, [&] { DoInitOnce(nullptr, nullptr); });

    const std::vector<std::uint8_t> input(data, data + size);

    processor p;
    (void)p.process(input);

    return 0;
}