On Thu, May 18, 2023 at 12:18 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > As a means to continue the discussion in [1], which is > concerned with finding the best long-term solution to > having a BPF Type Format (BTF) representation of > functions that is usable for tracing of edge cases, this > proof-of-concept series is intended to explore one approach > to adding information to help make tracing more accurate. > > A key problem today is that there is no matching from function > description to the actual instances of a function. > > When that function only has one description, that is > not an issue, but if we have multiple inconsistent > static functions in different CUs such as > > From kernel/irq/irqdesc.c > > static ssize_t wakeup_show(struct kobject *kobj, > struct kobj_attribute *attr, char *buf) > > ...and from drivers/base/power/sysfs.c > > static ssize_t wakeup_show(struct device *dev, struct device_attribute *attr, > char *buf); > > ...this becomes a problem. If I am attaching, > which do I want? And even if I know which one > I want, which instance in kallsyms is which? > As you described in the above example, it is natural to attach a *function* defined in a specific *file_path*. So why not encoding the file path instead ? What's the problem in it? If we expose the addr and let the user select which address to attach, it will be a trouble to deploy a bpf program across multiple kernels. While the file path will have a lower chance to be conflict between different kernel versions. So I think it would be better if we use the file path instead and let the kernel find the address automatically. In the old days, when we wanted to deploy a kprobe kernel module or a systemtap script across multiple kernels, we had to use if-else in the code, which was really troublesome as it is not scalable. I don't think we want to do it the same way in the bpf program. > This series is a proof-of-concept that supports encoding > function addresses and associating them with BTF FUNC > descriptions using BTF declaration tags. > > More work would need to be done on the kernel side > to _use_ this representation, but hopefully having a > rough approach outlined will help make that more feasible. > > [1] https://lore.kernel.org/bpf/ZF61j8WJls25BYTl@krava/ > > Alan Maguire (6): > btf_encoder: record function address and if it is local > dwarf_loader: store address in function low_pc if available > dwarf_loader: transfer low_pc info from subtroutine to its abstract > origin > btf_encoder: add "addr=0x<addr>" function declaration tag if > --btf_gen_func_addr specified > btf_encoder: store ELF function representations sorted by name _and_ > address > pahole: document --btf_gen_func_addr > > btf_encoder.c | 64 +++++++++++++++++++++++++++++++++++----------- > btf_encoder.h | 4 +-- > dwarf_loader.c | 16 +++++++++--- > dwarves.h | 3 +++ > man-pages/pahole.1 | 8 ++++++ > pahole.c | 12 +++++++-- > 6 files changed, 85 insertions(+), 22 deletions(-) > > -- > 2.31.1 > -- Regards Yafang
