On Tue, Sep 13, 2022 at 6:23 PM Grant Seltzer Richman <grantseltzer@xxxxxxxxx> wrote: > > Hi all, I'm experiencing an issue that I want to discuss, though I'm > not sure libbpf code is at fault. Any guidance is much appreciated. > > The behavior I'm seeing is that I have a `struct bpf_object_open_opts` > where I properly set each of the `btf_custom_path` and `kconfig` > fields. I then call `bpf_object__open_mem` with this opts struct and > get this error: > > libbpf: failed to get EHDR from /proc/config.gz > > The very important thing to note here is that I'm setting the fields > and calling bpf_object__open_mem from Go code using CGO (this is in > libbpfgo). I do believe it's likely to be a CGO issue and not libbpf > itself, but here's why: > > I've `git bisect`'ed the issue to be caused by commit `d8454ba8`, > which leads me to believe that CGO is failing to adjust offsets for > whatever having `long :0` in bpf_object_open_opts does. I can't figure > out why this was added, what exactly does that do? Is it some type of > added padding? Is it possible this isn't CGO? Yes, the intent was to have a hole between pin_root_path and kconfig. But this is a bug, my commit actually changed the layout of bpf_object_open_opts, unintentionally, because if long: 0 is already at long-aligned offset (which it is in this case) it does nothing, instead of shifting next field to next long-aligned offset. So bpf_object_open_opts is basically broken in libbpf 1.0. Thanks for the report! I'll send a fix shortly and we'll need to release 1.0.1 bug fix release. > > Thanks for any help, > Grant
