From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752503AbbGNLzB (ORCPT ); Tue, 14 Jul 2015 07:55:01 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:13719 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751644AbbGNLzA (ORCPT ); Tue, 14 Jul 2015 07:55:00 -0400 Subject: Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event To: Alexei Starovoitov , pi3orama , Namhyung Kim 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> <55A46928.9090708@plumgrid.com> CC: "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" From: He Kuang Message-ID: <55A4F869.1020705@huawei.com> Date: Tue, 14 Jul 2015 19:54:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <55A46928.9090708@plumgrid.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.110.54.65] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Alexei On 2015/7/14 9:43, Alexei Starovoitov wrote: > 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. We are turning to obtain infomation from dwarf_info, but still we should store the struct type in the bpf output raw data, otherwise perf tools can not distinguish different bpf trace points if there're multiple trace points in bpf program, because all the bpf_output sample entries has the same id. > 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 :) > I found objdump can't get dwarf info from bpf object file: $ objdump --dwarf=info bpf.o bpf.o: file format elf64-little $ readelf -a bpf.o |grep debug_info '-g' and '-gdwarf=4' options are added to clang flags, and if we compile object file for other platform such as x86_64, there's no problem. $ objdump --dwarf=info x86_64_xx.o |wc -l 179 $ readelf -a x86_64_xx.o |grep debug_info [10] .debug_info PROGBITS 0000000000000000 000002b9 I'm not very familar with llvm so can you give me some suggestions? Thank you.