wip: bpftool but with aya

[dave-tucker]

This change is 

[netlify]

✅ Deploy Preview for aya-rs-docs ready!

Name	Link
🔨 Latest commit	1d75213
🔍 Latest deploy log	https://app.netlify.com/sites/aya-rs-docs/deploys/65ea45cb3050fe0008a4cf27
😎 Deploy Preview	https://deploy-preview-902--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tamird]

Neat. Would be good to mention motivation of course.

Reviewed 6 of 7 files at r1, all commit messages.
Reviewable status: 6 of 7 files reviewed, 12 unresolved discussions

---

aya-tool/Cargo.toml line 12 at r1 (raw file):

[dependencies]
aya-obj = { version = "0.1.0", path = "../aya-obj", features = ["std"] }

do we need to state the version?

---

aya-tool/src/bin/aya-tool.rs line 27 at r1 (raw file):

        bindgen_args: Vec<String>,
    },
    /// Pretty print an ELF file's BTF

FYI there is https://github.com/anakryiko/btfdump. I didn't realize you were doing this until I got here in the review, it wasn't clear from the title

---

aya-tool/src/btf.rs line 6 at r1 (raw file):

use std::{fmt::Write, path::Path};

pub fn print_btf<P: AsRef<Path>>(path: P) -> anyhow::Result<()> {

can this take an impl io::Write and avoid all the intermediate allocations?

---

aya-obj/src/btf/types.rs line 85 at r1 (raw file):

        }
    }
    /// The target type of the const.

newline before this

---

aya-obj/src/btf/types.rs line 410 at r1 (raw file):

    }

    /// The integer size.

why not the same "The of the " phrasing you use elsewhere?

---

aya-obj/src/btf/types.rs line 425 at r1 (raw file):

    }

    /// The size of the integer in bits.

this isn't the size

---

aya-obj/src/btf/types.rs line 611 at r1 (raw file):

impl BtfMember {
    /// The offset of the members name in the BTF string section.

member's

---

aya-obj/src/btf/types.rs line 706 at r1 (raw file):

    }

    /// Vlen

?

---

aya-obj/src/btf/types.rs line 837 at r1 (raw file):

    }

    pub fn index_type(&self) -> u32 {

missing docs below this point.

---

aya-obj/src/btf/types.rs line 1480 at r1 (raw file):

    }

    /// Returns the name offset of the BTF type.

these comments start with "Returns" but the others do not

---

aya-obj/src/btf/btf.rs line 339 at r1 (raw file):

        use object::{Object, ObjectSection};
        let path = path.as_ref();
        let bin_data = std::fs::read(path).map_err(|e| BtfError::FileError {

nit: call this error to avoid the colon below

---

aya-obj/src/btf/btf.rs line 343 at r1 (raw file):

            error: e,
        })?;
        let obj_file = object::File::parse(&*bin_data).map_err(|_| BtfError::Elf)?;

can we avoid throwing away the error?

---

aya-obj/src/btf/btf.rs line 347 at r1 (raw file):

            .section_by_name(".BTF")
            .ok_or_else(|| BtfError::InvalidHeader)?;
        let data = section.data().map_err(|_| BtfError::InvalidHeader)?;

can we avoid throwing away the error?

[dave-tucker]

Neat. Would be good to mention motivation of course.

The motivation was:

1. To provide a meaningful second user of the aya-obj crate. This actually exposed some cases where we were missing APIs for working with BTF for example.
2. To provide something that could be used by bpf-linker for it's compiletests
3. More users == more eyes on the BTF parser, which we want to be battle-hardened, not panic, and handle "unknown" types with gracefully.
4. A precursor to something like bpf2go, which would see aya be able to create a strongly-typed EbpfLoader from compiled bytecode. So you'd access: skeleton.global_var or skeleton.my_map directly vs having to make runtime fallible calls to .set_global or .maps_mut etc...

This is just a quick hack, but it's open to be carried if others see value in having this here.

[tamird]

This all makes sense to me. I'm supportive of carrying forward, particularly for the last mentioned goal which seems extremely valuable.