elf: allow WEAK binding for map

[chenhengqi]

It seems like the current implementation already allow __weak map. Lift the limit so that users can use ebpf-go with libbpf's usdt.bpf.h. There is a similar fix (0) for libbpf.

[lmb]

How does a weak map binding differ from a non-weak one? I would have expected at least one change which implements weak behaviour. At the very least this should have a test via loader.c or similar.

[chenhengqi]

How does a weak map binding differ from a non-weak one? I would have expected at least one change which implements weak behaviour. At the very least this should have a test via loader.c or similar.

My rough understanding is that a weak symbol can co-exist with a normal one and the linker will use the normal one.
In case weak symbols exist, the weak symbol will be used.

This PR is imcomplete, need to investigate how tetragon works with USDT.

[dylandreimerink]

How does a weak map binding differ from a non-weak one?

In general there are 3 typical uses for __weak:

• Allow a symbol to be overwritten, strong symbols with the same name are preferred over the weak symbols.
• Allowing symbols to be "optional"
• Forcing the compiler to assume replacement - Since a weak symbol can be replaced at link time, the compiler has to generate bytecode without "assumptions".

For maps, the last options does not make sense since the compiler already does not make assumptions since maps are global variables. And the second option also does not make sense, as far as I know you cannot have an optional map.

So overwriting the spec of the map from BPF seems to be the only reason. Like mentioned, libbpf's USDT implementation defines its maps as __weak.

They also define most of the functions that use this map as __weak. So presumably the intent is to define this map and library function with the intent of allowing people to expand them by including the library and then re-defining the helpers. The weak map would allow you to add more fields to the value type. I have not found any example of anyone actually using it that way, not any explanation/justification from the author of usdt.bpf.h.

I would have expected at least one change which implements weak behaviour.

usdt.bpf.h is tried to the usdt.c userspace logic in Libbpf. So it does not really make sense to use it together with cilium/ebpf. Therefor, there isn't really a use case/user right now.
If someone goes to the effort of making a Go library that implements the same logic as usdt.c does, such that is compatible on a map level, this would make sense. But until then, we simply might not need weak support for maps.