On Mon, 2023-01-16 at 15:10 +0000, Alan Maguire wrote: > On 13/01/2023 08:33, Andrii Nakryiko wrote: > > This patch set fixes and extends libbpf's bpf_tracing.h support for > > tracing > > arguments of kprobes/uprobes, and syscall as a special case. > > > > Depending on the architecture, anywhere between 3 and 8 arguments > > can be > > passed to a function in registers (so relevant to kprobes and > > uprobes), but > > before this patch set libbpf's macros in bpf_tracing.h only > > supported up to > > 5 arguments, which is limiting in practice. This patch set extends > > bpf_tracing.h to support up to 8 arguments, if architecture allows. > > This > > includes explicit PT_REGS_PARMx() macro family, as well as > > BPF_KPROBE() macro. > > > > Now, with tracing syscall arguments situation is sometimes quite > > different. > > For a lot of architectures syscall argument passing through > > registers differs > > from function call sequence at least a little. For i386 it differs > > *a lot*. > > This patch set addresses this issue across all currently supported > > architectures and hopefully fixes existing issues. syscall(2) > > manpage defines > > that either 6 or 7 arguments can be supported, depending on > > architecture, so > > libbpf defines 6 or 7 registers per architecture to be used to > > fetch syscall > > arguments. > > > > Also, BPF_UPROBE and BPF_URETPROBE are introduced as part of this > > patch set. > > They are aliases for BPF_KPROBE and BPF_KRETPROBE (as mechanics of > > argument > > fetching of kernel functions and user-space functions are > > identical), but it > > allows BPF users to have less confusing BPF-side code when working > > with > > uprobes. > > > > For both sets of changes selftests are extended to test these new > > register > > definitions to architecture-defined limits. Unfortunately I don't > > have ability > > to test it on all architectures, and BPF CI only tests 3 > > architecture (x86-64, > > arm64, and s390x), so it would be greatly appreciated if CC'ed > > people can help > > review and test changes on architectures they are familiar with > > (and maybe > > have direct access to for testing). Thank you. > > > > Cc: Alan Maguire <alan.maguire@xxxxxxxxxx> > > Cc: Ilya Leoshkevich <iii@xxxxxxxxxxxxx> > > Cc: Pu Lehui <pulehui@xxxxxxxxxx> > > Cc: Hengqi Chen <hengqi.chen@xxxxxxxxx> > > Cc: Vladimir Isaev <isaev@xxxxxxxxxxxx> > > Cc: Björn Töpel <bjorn@xxxxxxxxxx> > > Cc: Kenta Tada <Kenta.Tada@xxxxxxxx> > > Cc: Florent Revest <revest@xxxxxxxxxxxx> > > > > This is fantastic, a huge step forward! > > For the series (tested on aarch64): > > Tested-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > One question - I couldn't parse the s390x documentation (or find > anything else) which stated the function calling conventions for > that platform. Currently we support 5 register function call args > for s390x - is that the right number? Hi, you can find the s390x ABI documentation here: https://github.com/IBM/s390x-abi/releases/download/v1.6/lzsabi_s390x.pdf It's indeed 5 registers for normal calls: %r2-%r6. The other arguments are passed on stack (*(long *)(%r15 + 160), etc). For syscalls it's 6: %r2-%r7. That is specified in man 2 syscall. Best regards, Ilya
