Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752807AbbGNBnI (ORCPT ); Mon, 13 Jul 2015 21:43:08 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:33964 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751767AbbGNBnH (ORCPT ); Mon, 13 Jul 2015 21:43:07 -0400 Message-ID: <55A46928.9090708@plumgrid.com> Date: Mon, 13 Jul 2015 18:43:04 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: pi3orama , Namhyung Kim CC: He Kuang , "rostedt@goodmis.org" , "masami.hiramatsu.pt@hitachi.com" , "acme@kernel.org" , "a.p.zijlstra@chello.nl" , "mingo@redhat.com" , "jolsa@kernel.org" , "wangnan0@huawei.com" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event References: <1436522587-136825-1-git-send-email-hekuang@huawei.com> <1436522587-136825-4-git-send-email-hekuang@huawei.com> <55A042DC.6030809@plumgrid.com> <55A3404B.6020904@huawei.com> <20150713135223.GB9917@danjae.kornet> <4D441676-21A7-46EE-AAB0-EB529D408082@163.com> <20150713140915.GD9917@danjae.kornet> In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1718 Lines: 49 On 7/13/15 7:29 AM, pi3orama wrote: >>>> I was thinking about providing custom event formats for each bpf >>>> >>>program (if needed). The event format definitions might be in a >>>> >>>specific directory or a bpf object itself. Then perf can read those >>>> >>>formats and print the output data according to the formats. Maybe we >>>> >>>need to add some dynamic event id to match format and data. >>> >> >>> >>I think we can do it in perf side. Let BPF programs themselves >>> >>encode format information into the array and make perf read and >>> >>decode them. In kernel side simply support raw data should be >>> >>enough, so we can make kernel code as simple as possible. >> > >> >Yes, of course, I also meant that doing those work all in perf side. :) sounds like a great idea. +1 > I have an idea on it: > > struct x{ > int a; > int b; > }; > struct x __x; > > SEC(...) > int func(void *ctx) > { > struct x myx; > ... > myx.a = 1; > myx.b = 2; > OUTPUT(&myx, &__x); > ... > } > > In the above program, the '&' operator will emit a relocation, relocation once emitted will be painful to remove from compiled code. Why not to use dwarf info from the struct passed into bpf_output_trace_data()? No extra macros would be needed from users. I'm not sure llvm generates proper dwarf along with bpf code (I didn't test that part. If there are any issues they should be fixable. If you can prepapre a patch for llvm that would be even better :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/