Currently we only use DWARF as a source of stack usage information. DWARF focuses on providing a source to runtime mapping for debuggers. This means that stack usage that was not part of the original sources such as spilling of register values holding intermediate values of expressions may no get entries in DWARF. This leaves gaps in the output such as:
go run ./cmd/stackwhere p testdata/host_1.o tail_nodeport_nat_egress_ipv6
R10-56:
4 - sum @ /home/dylanr/Documents/work/cilium/bpf/lib/nat.h:1587
4 - to @ /home/dylanr/Documents/work/cilium/bpf/lib/csum.h:75
Where there is 56 bytes worth of stack space at the bottom for which no DWARF entries can be found.
So it would be nice to find a way to annotate this missing space. Some ideas:
- Parse the collection with cilium/ebpf, analyze the eBPF instructions to find usage of these stack offsets.
- Use DWARF / BTF line info to work backwards from instructions to find approximate locations for spills.
- Use additional information sources such as verifier logs or clang outputs (register allocator debug output / LLVM IR) to get better information.
Currently we only use DWARF as a source of stack usage information. DWARF focuses on providing a source to runtime mapping for debuggers. This means that stack usage that was not part of the original sources such as spilling of register values holding intermediate values of expressions may no get entries in DWARF. This leaves gaps in the output such as:
Where there is 56 bytes worth of stack space at the bottom for which no DWARF entries can be found.
So it would be nice to find a way to annotate this missing space. Some ideas: