On Fri, Aug 30, 2024 at 06:26:10PM -0700, Eduard Zingerman wrote:
On Fri, 2024-08-30 at 14:25 -0700, Andrii Nakryiko wrote:
[...]
err = bpf_object__elf_init(obj);
err = err ? : bpf_object__check_endianness(obj); err = err ? : bpf_object__elf_collect(obj); err = err ? : bpf_object__collect_externs(obj); err = err ? : bpf_object_fixup_btf(obj);@@ -8500,6 +8529,10 @@ static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const ch
if (obj->gen_loader) bpf_gen__init(obj->gen_loader, extra_log_level, obj->nr_programs, obj->nr_maps);nit: add {} around if, both sides should either have or not have {}
else if (!is_native_endianness(obj)) {pr_warn("object '%s' is not native endianness\n", obj->name);"object '%s': load is not supported in non-native endianness\n"
return libbpf_err(-LIBBPF_ERRNO__ENDIAN);}Silly question: why load is allowed to proceed for non-native endianness when obj->gen_loader is set?
Not silly, had similar questions. Having obj->gen_loader set means "light skeleton" is being generated, where it tries to eliminate dependency on libbpf by skeleton code. In this mode, the code doesn't load anything but instead tracks "what would libbpf do" so it can later write a pure BPF loader program. Alexei will correct me or elaborate as needed I hope.
Unconditionally blocking on non-native endianness would break light skel.