Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754440AbbHFGzx (ORCPT ); Thu, 6 Aug 2015 02:55:53 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:33560 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752098AbbHFGzw (ORCPT ); Thu, 6 Aug 2015 02:55:52 -0400 Date: Wed, 5 Aug 2015 23:55:49 -0700 From: Alexei Starovoitov To: "Wangnan (F)" Cc: Alexei Starovoitov , He Kuang , pi3orama , llvm-dev@lists.llvm.org, "linux-kernel@vger.kernel.org" Subject: Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event Message-ID: <20150806065548.GB52262@Alexeis-MBP.westell.com> References: <55BB4B8A.5000207@huawei.com> <55BFC4A0.9060100@plumgrid.com> <55C07F5B.6030107@huawei.com> <55C16DC7.70408@huawei.com> <55C16F53.3070604@huawei.com> <55C1B254.5030801@huawei.com> <55C1B717.60501@plumgrid.com> <55C1C91D.5080007@huawei.com> <20150806032221.GA52057@Alexeis-MBP.westell.com> <55C2E412.70503@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C2E412.70503@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2519 Lines: 75 On Thu, Aug 06, 2015 at 12:35:30PM +0800, Wangnan (F) wrote: > > > On 2015/8/6 11:22, Alexei Starovoitov wrote: > >On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote: > >>It doesn't work for me at first since in my llvm there's only > >>llvm.bpf.load.*. > >> > >>I think llvm.bpf.store.* belone to some patches you haven't posted yet? > >nope. only loads have special instructions ld_abs/ld_ind > >which are represented by these intrinsics. > >stores, so far, are done via single bpf_store_bytes() helper function. > > > >>>the typeid changing ids with order is surprising. > >>>I think the assertion in ExtractTypeInfo() is not hard. > >>>Just there were no such use cases. May be we can do something > >>>similar to what LowerIntrinsicCall() does and lower it differently > >>>in the backend. > >>> > >>But in backend can we still get type information? I thought type is > >>meaningful in frontend only, and backend behaviors is unable to affect > >>DWARF generation, right? > >why do we need to affect type generation? we just need to know dwarf > >type id in the backend, so we can emit it as a constant. > >I still think lowering eh_typeid_for differently may work. > >Like instead of doing > >GV = ExtractTypeInfo(I.getArgOperand(0)) followed by > >getMachineFunction().getMMI().getTypeIDFor(GV) > >we can get dwarf type id from I.getArgOperand(0) if it's > >any pointer to struct type. > > I have a bad news to tell: > > #include > struct my_str { > int x; > int y; > } __gv_my_str; > struct my_str __gv_my_str_; > > struct my_str2 { > int x; > int y; > } __gv_my_str2; > > int typeid(void *p) asm("llvm.eh.typeid.for"); > > int main() > { > printf("%d\n", typeid(&__gv_my_str)); > printf("%d\n", typeid(&__gv_my_str_)); > printf("%d\n", typeid(&__gv_my_str2)); > return 0; > } > > Compiled with clang into x86 executable, then: > > $ ./a.out > 3 > 2 > 1 > > See? I have two types but reported 3 IDs. that's expected. We don't have to use default lowering of typeid_for with getTypeIDFor. bpf backend specific lowering can be different, though in this case it's odd that id for __gv_my_str and __gv_my_str_ are different. __gv_my_str and __gv_my_str2 should be different. -- 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/