Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752178AbbHEI7s (ORCPT ); Wed, 5 Aug 2015 04:59:48 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:59141 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751093AbbHEI7o (ORCPT ); Wed, 5 Aug 2015 04:59:44 -0400 Subject: Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event To: Alexei Starovoitov , "Wangnan (F)" , pi3orama 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> <55A4F869.1020705@huawei.com> <55A88085.8090407@plumgrid.com> <55A88137.7020609@huawei.com> <55A88449.3030008@plumgrid.com> <55B0D5FC.6050406@huawei.com> <55B1535E.8090406@plumgrid.com> <55B1AEE9.1080207@plumgrid.com> <55B1BC03.9020708@huawei.com> <55B35F42.70803@huawei.com> <55B6E685.30905@plumgrid.com> <55B89F04.5030304@huawei.com> <55B909B2.2080606@plumgrid.com> CC: "linux-kernel@vger.kernel.org" , From: He Kuang Message-ID: <55C1D055.2050205@huawei.com> Date: Wed, 5 Aug 2015 16:59:01 +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: <55B909B2.2080606@plumgrid.com> Content-Type: text/plain; charset="utf-8"; 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 Content-Length: 2227 Lines: 56 Hi, Alexei On 2015/7/30 1:13, Alexei Starovoitov wrote: > On 7/29/15 2:38 AM, He Kuang wrote: >> Hi, Alexei >> >> On 2015/7/28 10:18, Alexei Starovoitov wrote: >>> On 7/25/15 3:04 AM, He Kuang wrote: >>>> I noticed that for 64-bit elf format, the reloc sections have >>>> 'Addend' in the entry, but there's no 'Addend' info in bpf elf >>>> file(64bit). I think there must be something wrong in the process >>>> of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the >>>> AT_name now, DW_AT_LOCATION still missed and need your help. >>> Another thing about DW_AT_name, we've already found that the name string is stored indirectly and needs relocation which is architecture specific, while the e_machine info in bpf obj file is "unknown", both objdump and libdw cannot parse DW_AT_name correctly. Should we just use a known architeture for bpf object file instead of "unknown"? If so, we can use the existing relocation codes in libdw and get DIE name by simply invoking dwarf_diename(). The drawback of this method is that, e.g. we use "x86-64" instead, is hard to distinguish bpf obj file with x86-64 elf file. Do you think this is ok? Otherwise, for not touching libdw, we should reimplement the relocation codes already in libdw for bpf elf file with "unknown" machine info specially in perf. I wonder whether it is worth doing this and what's your opinion? Thank you. >> index directly: >> >> __bpf_trace_output_data(__builtin_dwarf_type(myvar_a), &myvar_a, size); >> > > probably both A and B won't really work when programs get bigger > and optimizations will start moving lines around. > the builtin_dwarf_type idea is actually quite interesting. > Potentially that builtin can stringify type name and later we can > search it in dwarf. Please take a look how to add such builtin. > There are few similar builtins that deal with exception handling > and need type info. May be they can be reused. Like: > int_eh_typeid_for and int_eh_dwarf_cfa > > -- 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/