Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

declaring a map requires having a field named type #54

Closed
dvc94ch opened this issue Jan 17, 2021 · 9 comments
Closed

declaring a map requires having a field named type #54

dvc94ch opened this issue Jan 17, 2021 · 9 comments

Comments

@dvc94ch
Copy link

dvc94ch commented Jan 17, 2021

This can not be accomplished when compiling from rust. type_ as emitted by bindgen or r#type generate wrong identifier names in the debug info making it impossible to get btf to acknowledge a type field. I'd suggest also accepting type_.

Ups wrong repo should be the libbpf one.

@danobi
Copy link
Member

danobi commented Jan 20, 2021

Gonna close this out b/c it's probably better asked on the bpf mailing lists.

But just out of curiosity, why are you bindgen'ing the .bpf.c code?

@danobi danobi closed this as completed Jan 20, 2021
@dvc94ch
Copy link
Author

dvc94ch commented Jan 20, 2021

But just out of curiosity, why are you bindgen'ing the .bpf.c code?

I'm not. Currently I'm using a patched cargo-bpf that emits debug info [0], at least until the rustc bpf target support is merged [1]. I'm currently working on my own bpf library that is going to work something like this:

let bpf = BpfBuilder::new(PROBE)?
    .attach_probe("tracepoint:raw_syscalls:sys_enter", "sys_enter")?
    .attach_probe("tracepoint:raw_syscalls:sys_exit", "sys_exit")?
    .attach_probe("profile:hz:99", "profile")?
    .load()?;

I'm still missing an understanding of how maps work in detail, I assumed libbpf-rs would handle it for me until I realized it does not.

So you used to be able to declare a map using the bpf_map_def struct but now it is inferred in a weird (for every language that isn't C) way [3].

@dvc94ch
Copy link
Author

dvc94ch commented Jan 20, 2021

Any suggestions on how to proceed? I guess I'll just not put maps in the .maps section and load them manually using the bpf(BPF_MAP_CREATE) syscall.

@anakryiko
Copy link
Member

It's not clear. So how does your BPF code look like?

@dvc94ch
Copy link
Author

dvc94ch commented Jan 21, 2021

It's a work in progress, I made my first experiments with redbpf and got something to work (counting syscalls). Here is the wip adaption to my own library [0]. Note that nothing actually works yet.

@anakryiko
Copy link
Member

redbpf doesn use libbpf. Those BTF-based map definitions in SEC(".maps") is libbpf convention. Kernel itself just expects BTF FD and type IDs associated with key and value to get everything working.

On the other hand, libbpf does expect BPF code to be written in C and compiled with Clang. So if you want to go with Rust for BPF code, I don't think you can easily use libbpf.

@dvc94ch
Copy link
Author

dvc94ch commented Jan 21, 2021

Yes I came to the same conclusion. I can still use libbpf-rs to bootstrap, it should work for parsing the elf file and loading bpf programs, but I'll need to implement my own map handling.

@dvc94ch
Copy link
Author

dvc94ch commented Jan 22, 2021

libbpf-rs works for me now. apparently you can put maps in a maps section instead of a .maps section and it just works. the verifier seems mysterious sometimes, is there a good reference explaining what it verifies and how to make it happy?

@danobi
Copy link
Member

danobi commented Jan 23, 2021

the verifier seems mysterious sometimes, is there a good reference explaining what it verifies and how to make it happy?

Unfortunately, the only way is to read the source. Usually the function names will hint you in the right direction.

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

No branches or pull requests

3 participants