On Sat, Mar 20, 2021 at 10:18:36AM -0700, Andrii Nakryiko wrote: > > From test_ksyms.c: > > [22] DATASEC '.ksyms' size=0 vlen=5 > > type_id=12 offset=0 size=1 > > type_id=13 offset=0 size=1 > > > > For extern, does it make sense for the libbpf to assign 0 to > > both var offset and size since it does not matter? > > That's how it is generated and yes, I think that's how it should be > kept once kernel supports EXTERN VAR. libbpf is adjusting offsets and > sizes in addition to marking VAR itself as GLOBAL_ALLOCATED. If kernel > supports EXTERN VAR natively, none of that needs to happen (on newer > kernels only, of course). > > > In the kernel, it can ensure a datasec only has all extern or no extern. > > array_map_check_btf() will ensure the datasec has no extern. > > It certainly makes it less surprising from handling BTF, but it feels > like an arbitrary policy, rather than technical restriction. You can > mark allocated variables and externs with the same section name and > Clang will probably happily generate a single DATASEC with a mix of > externs and non-externs. Is that inherently a bad thing? I'm not sure. > Basically, I don't know if the kernel should care and enforce or not. I have thought a bit more on this. The offset=0 of extern var can be used in the verification but I think it will still have some open ended questions like arraymap. I will use your suggestion in libbpf and do something similar as the extern VAR: replace the FUNC in datasec with INT (btf__add_var() if needed). > > > > > > But of course to support older kernels libbpf will still have to > > > do this. EXTERN vars won't reduce the amount of libbpf logic.
