On 5/19/23 2:44 AM, Yafang Shao wrote:
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?
Say we have the following kernel code:
common.h:
static inline int foo(...) { ...}
bar1.c:
#include "common.h."
... foo() ...
bar2.c:
#include "common.h"
... foo() ...
Even if the function 'foo' is marked as inline, but the compiler
may not actually inline it. So now we got two static functions
'foo' in bar1.o and bar2.o with identical code path (common.h),
and we do want to differentiate it as user might want to
only trace one of them.
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.
user space may need a little bit work to decide which address to take
by looking at the vmlinux BTF intending to run, e.g., checking
BTF signatures in most time or in the worst case checking dwarf.
The kernel can then handle addr by doing some relocation if needed.
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
