Skip to content

Add ability to use LIBBPF_DEBUG=1 for BPF tests#503

Open
gmarler wants to merge 2 commits into
javierhonduco:mainfrom
gmarler:bpf-verifier-logs-for-tests
Open

Add ability to use LIBBPF_DEBUG=1 for BPF tests#503
gmarler wants to merge 2 commits into
javierhonduco:mainfrom
gmarler:bpf-verifier-logs-for-tests

Conversation

@gmarler

@gmarler gmarler commented Jul 1, 2026

Copy link
Copy Markdown
Contributor
  • This allows getting BPF verifier debug output when such tests fail

Comment thread src/profiler.rs
Self {
cache_dir_base: temp_dir(),
libbpf_debug: false,
libbpf_debug: std::env::var("LIBBPF_DEBUG").is_ok(),

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is false by default as it's a reasonable setting to have unless something it's set on purpose.

I recommend to either manually add it for each test such as it's done in

let bpf_test_debug = std::env::var("TEST_DEBUG_BPF").is_ok();
, or that a a constructor for testing purposes is created

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, can do that - but this keeps the value false by default (and has the benefit of only having to be set in one place with one change - which I thought was a virtue) - one has to set LIBBPF_DEBUG to get a value other than false.

Relatedly, did you want me to change LIBBPF_DEBUG to TEST_DEBUG_BPF, for consistency across the codebase? Or was the intent different?

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's too "magical" to use env vars for things like this, that's why I prefer hardcoding it / selecting it at runtime. The reason for this is that typically env vars are not very well documented.

I think TEST_LIBBPF_DEBUG makes more sense, definitely would be good to have a single env var name for this purpose. But as long as we are consistent on using one name I don't mind too much which one we choose!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants