You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working with BTF type information in ebpf.VariableSpec, the TypeName() method may return an empty string for certain types (like arrays), requiring recursive type resolution to get the actual type name.
Current Behavior
Currently, when calling Type.TypeName() directly on BTF types, it may return an empty string for composite types. For example:
member = {btf.Member}
├── Name = "comm"
└── Type = {btf.Type | *btf.Array}
├── Index = {btf.Type | *btf.Int}
└── Type = {btf.Type | *btf.Int}
├── Name = "char"
├── Size = 1
├── Encoding = Signed (1)
└── Nelems = 16
Direct call to TypeName() returns empty string, while the actual type should be char[16].
Expected Behavior
The type resolution should recursively traverse the type information until it finds a meaningful type name. For array types, it should include the array size in the format type[size].
How to reproduce
Create a minimal eBPF program with a global variable:
Create a Go program to inspect the BTF information:
package main
import (
"fmt""log""github.com/cilium/ebpf""github.com/cilium/ebpf/btf"
)
funcmain() {
// Load the eBPF programspec, err:=ebpf.LoadCollectionSpec("example.bpf.o")
iferr!=nil {
log.Fatalf("loading spec: %v", err)
}
// Inspect global variablesforname, varSpec:=rangespec.Variables {
fmt.Printf("Variable: %s\n", name)
// Get BTF type informationbtfType:=varSpec.Type().Type// If it's a pointer type, try to get the target structifptr, isPtr:=btfType.(*btf.Pointer); isPtr {
iftarget, isStruct:=ptr.Target.(*btf.Struct); isStruct {
fmt.Printf("Struct: %s\n", target.Name)
// Print struct membersfor_, member:=rangetarget.Members {
fmt.Printf("Member: %s, Type: %s\n",
member.Name,
member.Type.TypeName()) // This will be empty for arrays
}
}
}
}
}
Build and run:
# Compile the eBPF program
clang -target bpf -g -O2 -c example.bpf.c -o example.bpf.o
# Run the Go program
go run main.go
Expected output:
Variable: unused_event
Struct: event
Member: comm, Type: # Empty string instead of "char[16]"
Member: pid, Type: int
This demonstrates that TypeName() returns an empty string for array types, making it difficult to get the complete type information without recursive type resolution.
Version information
github.com/cilium/ebpf v0.17.2
The text was updated successfully, but these errors were encountered:
Good observation! This is not related to VariableSpec, though. Would you be up for sending a patch? I likely won't get to this in the coming weeks, I'll be out on PTO.
ti-mo
changed the title
BTF Type Name Resolution Issue in ebpf.VariableSpec
btf.Array.TypeName() returns empty string
Feb 26, 2025
ti-mo
changed the title
btf.Array.TypeName() returns empty stringbtf.Array.TypeName() returns empty string
Feb 26, 2025
Describe the bug
Issue Description
When working with BTF type information in
ebpf.VariableSpec
, theTypeName()
method may return an empty string for certain types (like arrays), requiring recursive type resolution to get the actual type name.Current Behavior
Currently, when calling
Type.TypeName()
directly on BTF types, it may return an empty string for composite types. For example:Consider this BTF type structure:
Direct call to
TypeName()
returns empty string, while the actual type should bechar[16]
.Expected Behavior
The type resolution should recursively traverse the type information until it finds a meaningful type name. For array types, it should include the array size in the format
type[size]
.How to reproduce
This demonstrates that
TypeName()
returns an empty string for array types, making it difficult to get the complete type information without recursive type resolution.Version information
github.com/cilium/ebpf v0.17.2
The text was updated successfully, but these errors were encountered: