ebpf: Always use release profile

Using `dev` profile, even after tuning flags (to make it identical
with `release`) still causes problems and is confusing for people.

And even when we have BTF support in future, it'd be better and
less confusing to set `debug=2` in `release` profile (because we
would want debug info, but still keep the same opt-level and other
options).

xtask/src/build_ebpf.rs

@@ -44,14 +44,12 @@ pub fn build_ebpf(opts: Options) -> Result<(), anyhow::Error> {
     let target = format!("--target={}", opts.target);
     let mut args = vec![
         "build",
+        "--release",
         "--verbose",
         target.as_str(),
         "-Z",
         "build-std=core",
     ];
-    if opts.release {
-        args.push("--release")
-    }
 
     // Command::new creates a child process which inherits all env variables. This means env
     // vars set by the cargo xtask command are also inherited. RUSTUP_TOOLCHAIN is removed

{{project-name}}-ebpf/Cargo.toml

@@ -12,17 +12,6 @@ aya-log-ebpf = { git = "https://github.com/aya-rs/aya" }
 name = "{{ project-name }}"
 path = "src/main.rs"
 
-[profile.dev]
-opt-level = 3
-debug = false
-debug-assertions = false
-overflow-checks = false
-lto = true
-panic = "abort"
-incremental = false
-codegen-units = 1
-rpath = false
-
 [profile.release]
 lto = true
 panic = "abort"

{{project-name}}/src/main.rs

@@ -86,11 +86,6 @@ async fn main() -> Result<(), anyhow::Error> {
     // runtime. This approach is recommended for most real-world use cases. If you would
     // like to specify the eBPF program at runtime rather than at compile-time, you can
     // reach for `Bpf::load_file` instead.
-    #[cfg(debug_assertions)]
-    let mut bpf = Bpf::load(include_bytes_aligned!(
-        "../../target/bpfel-unknown-none/debug/{{project-name}}"
-    ))?;
-    #[cfg(not(debug_assertions))]
     let mut bpf = Bpf::load(include_bytes_aligned!(
         "../../target/bpfel-unknown-none/release/{{project-name}}"
     ))?;