cmake: Add option to disable LTO

[vcfxb]

Summary by CodeRabbit

• Chores
  • Added a configurable build option for link-time optimization in release builds (enabled by default). Users building from source can now control this behavior during the build configuration process.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 99b95140-4973-4f4d-88dc-9dd120f8eb29

📥 Commits

Reviewing files that changed from the base of the PR and between ce026ec and ed186a8.

📒 Files selected for processing (1)

• CMakeLists.txt

---

Walkthrough

Adds a CMake build option prevail_ENABLE_LTO (default ON) to conditionally enable link-time optimization in release builds. Previously, LTO was always enabled for GNU/Clang; now it's conditional based on the option, falling back to -O2 when disabled.

Changes

Cohort / File(s)	Summary
Build Configuration CMakeLists.txt	Added conditional CMake option for link-time optimization control in release builds, replacing unconditional -flto=auto flag with optional behavior.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'cmake: Add option to disable LTO' directly and accurately describes the main change—adding a CMake option to control link-time optimization behavior.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[elazarg]

Can you please explain the reason for this PR?

[vcfxb]

It's mostly an attempt to fix some strange linker errors I'm running into when trying to link prevail into a non-C/C++ library. Linking across ffi boundaries here has proven tricky (esp since one compiler uses lld, and the other uses gnu ld it seems), and having this upstreamed would prevent me from needing to maintain a fork or use a patch locally :/

[elazarg]

Does that work? I've linked across FFI boundary while making prevail-rust with no issues (of course that doesn't prove it's not an issue in some other setup)

[vcfxb]

Is prevail-rust stable and/or capable of being used in production? If so I can just use that here probably, rather than trying to continue arguing with lld.

[elazarg]

I believe it's as production ready as this project, but unless you're linking with Rust I don't think it matters too much. And I don't mind adding the flag, I only want to be sure it's useful.

[vcfxb]

The host project is in rust, yeah, so I can give prevail-rust a try. In terms of merging this, maybe we hold off until I figure out if prevail-rust works for my usecase. If it does, then I'm fine if this gets closed

[elazarg]

Cool. If you need any changes in prevail-rust, open a PR there.

[vcfxb]

The main thing I probably need is the flexibility of #1060. I'll open a PR on prevail-rust probably, not sure though if I should modify the platform trait or analyzer options. Will investigate further tomorrow

[vcfxb]

Ultimately, the thing that seemed least intrusive was just switching to single initialization locking statics, since rust doesn't support compile-time -D style definitions. elazarg/prevail-rust#2

[elazarg]

Wouldn't making them CLI parameters, passed with the rest of the config, the most proncipled solution?

[vcfxb]

How do you mean?

[elazarg]

Add it to ebpf_verifier_options_t.

[vcfxb]

There are references to the stack size from things like crab/bitset_domain that don't work if it's a runtime value rather than a compile time constant, I think

prevail/src/crab/bitset_domain.hpp

Line 14 in 1a19d6f

using bits_t = std::bitset<EBPF_TOTAL_STACK_SIZE>;

[elazarg]

There are references to the stack size from things like crab/bitset_domain that don't work if it's a runtime value rather than a compile time constant, I think

prevail/src/crab/bitset_domain.hpp

Line 14 in 1a19d6f

using bits_t = std::bitset<EBPF_TOTAL_STACK_SIZE>;

That's a nice type-level guarantee and optimization, but it's not essential and we already know it's not a real constant. We can use boost::dynamic_bitset (or roll our own).

[vcfxb]

Sorry, I'm a little confused. I mostly just want to be able to supply my own limits for stack size and the stack frame cap. It doesn't personally matter to me whether they're at compile time (using the define guards from #1060) or at initialization time (elazarg/prevail-rust#2). If elazarg/prevail-rust#2 gets merged, I can just use the rust library and close this PR. Are you asking me to rework that PR to have the stack size and frame cap in the verifier options, or are you asking me to update this repo to match that PR or are you asking for both? I was not sure whether having the stack size as a parameter of the verifier options made more sense than putting it in the platform configuration. In either case, there would be a lot more changes to the existing codebase, some of which I assume would be breaking (neither of the changes in #1060 or in elazarg/prevail-rust#2 interrupt library users so far).

[elazarg]

@vcfxb take a look at #1070. Is that what you need?

[vcfxb]

Yeah that would work!! I've switched over to using the rust library at this point, can we add that there as well?

[elazarg]

prevail-rust is a "mirror" of prevail, keeping character-level output parity. So yes.

[vcfxb]

Perfect, okay let's do that then

[vcfxb]

Should I close this now that #1070 is merged?

[elazarg]

I think so.