On Thu, Aug 14, 2014 at 11:08 PM, Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote: > On Thu, Aug 14, 2014 at 2:20 PM, Brendan Gregg > <brendan.d.gregg@xxxxxxxxx> wrote: >> On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote: >> [...] >>> +/* For tracing filters save first six arguments of tracepoint events. >>> + * On 64-bit architectures argN fields will match one to one to arguments passed >>> + * to tracepoint events. >>> + * On 32-bit architectures u64 arguments to events will be seen into two >>> + * consecutive argN, argN+1 fields. Pointers, u32, u16, u8, bool types will >>> + * match one to one >>> + */ >>> +struct bpf_context { >>> + unsigned long arg1; >>> + unsigned long arg2; >>> + unsigned long arg3; >>> + unsigned long arg4; >>> + unsigned long arg5; >>> + unsigned long arg6; >>> + unsigned long ret; >>> +}; >> >> While this works, the argN+1 shift for 32-bit is a gotcha to learn. >> Lets say arg1 was 64-bit, and my program only examined arg2. I'd need >> two programs, one for 64-bit (using arg2) and 32-bit (arg3). If there > > correct. > I've picked 'long' type for these tracepoint 'arguments' to match > what is going on at assembler level. > 32-bit archs are passing 64-bit values in two consecutive registers > or two stack slots. So it's partially exposing architectural details. > I've tried to use u64 here, but it complicated tracepoint+ebpf patch > a lot, since I need per-architecture support for moving C arguments > into u64 variables and hacking tracepoint event definitions in a nasty > ways. This 'long' type approach is the least intrusive I could find. > Also out of 1842 total tracepoint fields, only 144 fields are 64-bit, > so rarely one would need to deal with u64. Most of the tracepoint > arguments are either longs, ints or pointers, which fits this approach > the best. > In general the eBPF design approach is to keep kernel bits as simple > as possible and move complexity to user space. > In this case some higher language than C for writing scripts can > hide this oddity. The downside of this approach is that compat support might be difficult or impossible. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html