@d-e-s-o @ work

The rest looks reasonable.

No worries. Didn't get a chance to take another look today, but should be able to review tomorrow.

Plenty of questions still remain unanswered, so no point in giving it another pass to ask for clarification on the same topics.

Yeah, if you want to run the tests you should check out the source code. There is no guarantee that published bundles can be tested. Is that a requirement for...

Can you provide an fully working example, please? I think we should be dumping all types available in BTF, which includes keys and values used in BPF maps.

I suppose it may be a compatibility feature for when different page sizes are available at runtime. I guess the kernel has to work with a minimum size of 4k...

My take is that this is an Android kernel bug introduced as part of the conversion from 4k pages to 16k: https://android.googlesource.com/kernel/common/+/8c2a805a857914324b077708b45c31c2f20d02da The patch claims to be non-breaking but that...

I reached out to Kalesh who implemented most if not all of this logic. You can probably disable https://docs.rs/blazesym/latest/blazesym/symbolize/source/struct.Process.html#structfield.map_files to circumvent the problem.

I think a dance like what @javierhonduco suggests may be necessary at the moment. We should check whether we can improve, but it would be helpful to have a minimal...

Sorry for the delayed response, I was on vacation. As https://github.com/libbpf/libbpf-rs/commit/c01e9b9bb1cf2bbde195de3f194d8f09972922b3 states, the main driver for the rework is the desire to access multiple maps/programs mutably. Here is a trivial...