Replies: 1 comment
-
Reading constants is now possible with #1564 and will ship in 0.17. Manual is here: https://ebpf-go.dev/concepts/global-variables. However, this strikes me as rather roundabout, esp. since we cull unreferenced symbols as you've mentioned. This cannot be worked around (aside from creating a reference..) and is still the case with the new CollectionSpec.Variables implementation. For carrying e.g. some version info or other build-time info in an ELF, consider putting them in enums. Your
Try this in C: enum metadata { bar = 1 };
// __hidden to omit from CollectionSpec.Variables. You could make this static,
// but then you'll need to mark it with __attribute__((used)), pick your poison..
// In the ELF, these would look exactly the same.
__hidden volatile enum metadata __meta; bpftool:
In Go: var consts *btf.Enum
if err := spec.Types.TypeByName("metadata", &consts); err != nil {
panic(err)
}
for _, v := range consts.Values {
if v.Name == "non_exist" {
return v.Value
}
} Hope this helps. |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
Hopefully I've not missed the obvious here ... to the best of my knowledge there isn't currently "an official" way to keep constant/
#define
definitions synchronized between the eBPF C side and associated Go code. However, the opposite direction is supported viaebpf.CollectionSpec.RewriteConstants
.A potential
ebpf.CollectionSpec.GetConstants(consts map[string]any) error
would allow (albeit only at runtime) the Go side of code to pick up constant definitions and be always in sync; no more duplicate definition with#define
in the eBPF program, and potentially out-of-sync Goconst
s.For instance, in the eBPF C code:
Nota bene: I found out the hard way that
elfCode.loadDataSections
skips sections (including.rodata
) when they aren't referenced in any way by program sections.How to reproduce
n/a
Version information
github.com/cilium/ebpf v0.16.0
Beta Was this translation helpful? Give feedback.
All reactions